I need a cellphone application that sends a http request and then saves the http response.
The reason I want this is to make sure that the response sent from our server to the mobile is the same as the response the mobile receive. We are currently expecting that some mobile operators are modifying the response. So we would like to know what they modify.
I have access to a bunch of phones: but I would prefer Symbian s60 or windows mobile.
For a Windows Mobile application, check out "Debugging a HTTP Request" at this sample telnet client (CodeProject)
Related
I am currently building a web + mobile application.
My front end is developed using React and Axios (for API call requests). It is served directly by vercel on mydomain.com
My Mobile App is developed using the Flutter
My back end is developed using Django and Django Rest. It is served with apache2 on api.mydomain.com. It only serves API endpoints.
So the front-end, Mobile app, and back-end are separated.
I would like only my front-end (mydomain.com) and flutter app to be able to make API requests to my Django Rest backend.
I would like to prevent any other domains, any clients such as postman, insomnia, curl, or any script to make API requests to my backend.
I have already set CORS in Django Rest. However, I can still make requests to the backend using curl or any other client.
Do you have any idea of what I could do to achieve this?
Thanks a lot in advance for your answers.
CORS is enforced only by web browsers to prevent leaking information to unrelated pages that might request it. You need some kind of access control, either by authenticating the caller or limiting access to the endpoint.
Checking the Host header with get_host() may offer sufficient protection, depending on your server setup.
get_host() will tell you the value of the Host header in the request, which is data provided by the client so could be manipulated in any way. The Host header is an integral part of HTTP 1.1 in allowing multiple domains to be hosted at a single address so you might be able to depend on your server rejecting requests that aren't actually arriving from localhost with a matching header, but it's difficult to be certain.
It would likely be more reliable to check the client's network address and reject requests from all clients except those that are specifically allowed.
Check this question too.
I can request to a API very easily in Postman. But when I try it with React JS and on localhost:3000, it throws me an error:
Please tell me why?! Thanks
See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/
If you know CORS problems, it would be easier to explain.
Because the requests sent by Postman or ones by your React.JS are kind of different.
As you send requests with Postman directly, the requests are considered sent by as "a person", like you enter the URLs of your APIs in your browser.
It's different with sending requests with React because React is a front-end JavaScript based framework language "executed" by your browser.
Imaging if you happen to access a malicious web-site, and the site sends intended codes of React(or some JavaScript) to manipulate your browser(An easy example: If there are no limits, it can use your browser as a web crawler to other sites).
You know that every time you open a site, your browser is executing lots of codes from the site.
So you may have to understand why we need CORS policy, and how CORS works to develop your APIs.
I am having difficulties testing my application on Ionic View or iOS emulator.
When I run my app from browser (ionic serve --lab) I am able to send the login http post request, get a proper response and login. However, when I test my app from ionic view or ios emulator, my http request does not seem to be even sent as I get a strange response status code of -1 and no response data (null).
just to note my server has been set up to accept the CORS and it allows cross origin requests.
Has anyone had any similar issue?
Any help or instruction would be much appreciated.
Thanks,
I am working on a silverlight app that is using browser HTTP stack to communicate with the server (restful service). When the server responds to requests from this app, it uses custom HTTP headers to provide extra information for the client.
Unfortunately, we are unable to extract these custom headers in the silverlight app. It seems that the custom headers are removed by the browser HTTP stack, before we can process them.
Is this a known issue? Can we do anything to be able to read these custom HTTP header fields?
According to the documentation, the custom response headers are only supported in Client HTTP stack:
How to: Specify Browser or Client HTTP Handling
Is is must to have the client to be browser for a web server? Is this a good architecture for mobile clients to have some non browser client and get data from webservers?
I am thinking of implementing a basic browser at mobile client. Login using web methos and rest of the communication (monitoring info at every 10sec) be done using web sockets. Will this work?
Can I implement web sockets without JS?
Thanks
You can implement WebSockets outside the browser, and without any JavaScript involved. You could have i.e. a Android native Java application that talks to a server over WebSockets.
WebSockets is a protocol. The WebSockets API defined for JavaScript running in the browser is something different.
You can authenticate a WebSockets connection during the WebSockets handshake using any method available with HTTP (i.e. basic auth, digest, cram-md5, client cert.-based (TLS), and so on), since the WebSockets handshake is still like any other HTTP conversation. It is only after the handshake is completed that WS is different from HTTP.
Note, that what you likely want on the server side is not a plain old Web server, but a WebSockets server/framework.
Whether using WS to connect mobile clients is "a good architecture" is a bit vague. I would say: if you decide to have your mobile client talk to a server, and that server is under your control, and you want to leverage WS advantages like near real-time/bidirectional, then it might be good. Better than cooking your own low-level protocol.