Our tester captured some unknown GET request while doing API testing in our React Native application.
GET /inspector/device?name=some_unique_id&app=com.companyname.appname HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: encrypted key
Sec-WebSocket-Version: 13
Host: localhost:8082
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
Could someone give me some idea what is this and why is this called.?
Thanks.
It seems the line may comes from RCTInspectorDevServerHelper.mm. You can see the line
return [NSURL URLWithString:[NSString stringWithFormat:#"http://%#/inspector/device?name=%#&app=%#",
getServerHost(bundleURL, inspectorProxyPort),
escapedDeviceName,
escapedAppName]];
inside getInspectorDeviceUrl function, which seems to be called each time the app is loaded to connect with the bundle.
Related
I'm creating a simple proxy server and I've run into an issue with getting responses back from a website.
I've set up my server to accept connections on a specified port that gets connected to through the browser proxy config. The server is able to receive the request, connect to the specified website, send the request, and receive a reply.
I'm forwarding the request from the browser to the website without modification, but the replies I receive are always 404 errors.
This is the request I'm fowarding to the website, there is a \r\n after every line and \r\n\r\n after the final line.
GET http://www.mywebpage.com/ HTTP/1.1
Host: www.mywebpage.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: __utma=1.35811746.1525489860.1537250282.1539467023.3; __utmz=1.1537250282.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); _fbp=fb.1.1553849756364.1600689742
Upgrade-Insecure-Requests: 1
My send receive code looks like this.
sendError = send(serverSock, requestString , strlen(requestString) , 0 );
returnedSize = recv(serverSock, buffer, sizeof(buffer), 0);
I'm forwarding the request from the browser to the website without modification
...
GET http://www.mywebpage.com/ HTTP/1.1
The absolute URL you use in your request target should only be used for proxies. Normal servers expect the origin form, i.e. only the path and optional query but not the full URL. Method, host and port should thus be stripped:
GET / HTTP/1.1
I have a Google AppEngine project that works fine in production but not locally.
There is a React browser application running locally on port 3001 and a python api service running on 9090.
When I attempt to upload files via the React client, I first call an REST endpoint that returns the blobstore get_upload_url() to the client. This url is something like: http://localhost:9090/_ah/upload/aghkZXZ-... <-- note the port is that of the python service
When I fashion a POST request to that url from the browser client to actually upload the file, I get a 405 on the OPTIONS preflight check. So far as I understand, this is due to the ports being different. This only occurs in the local App Engine SDK since I am using dispatch.yaml settings in production to have everything on the same domain/port.
I had dug into the SDK code a while ago and put a hack in place. (https://gist.github.com/blainegarrett/4d3b3081d09b4ff7be00765eb32b0d94)
However, since upgrading Google Cloud to 218.0.0, the hack was overwritten and I'm back to square one.
Here are the headers to the blobstore upload url:
OPTIONS /_ah/upload/aghkZXZ-Tm9uZXIiCxIVX19CbG9iVXBsb2FkU2Vzc2lvbl9fGICAgICA77ALDA HTTP/1.1
Host: localhost:9090
Connection: keep-alive
Origin: http://localhost:3001
Access-Control-Request-Method: POST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
I am currently using vanilla XMLHttpRequest() for the upload call specifically.
Does anyone have any suggestion on how to either get around the preflight check when the ports are different and/or to allow OPTIONS checks on the upload url in a less hacky way?
Update: I'd still like to hear an answer regarding the 405 on the SDK, but I was able to dodge the preflight check by getting rid of the xhr progress listener. My original assertion that the port difference was triggering the preflight check was incorrect. It was the progress callback.
xhr.upload.addEventListener('progress', function(e) { .. }
See research on: CORS request is preflighted, but it seems like it should not be
Pretty noobish question here, I do not wish to draw flak.
I have my frontend created with create-react-app and I'm using fetch to pass in the backend APIs to my frontend. The backend is running on localhost:8080 on the same machine as the frontend. Frontend is running on port 3000. I have hardcoded the URLs as "http://localhost:8080/getForm" and so on. It all works fine if I access the frontend on the same machine as it is hosted. However, if I access the frontend from a different machine, the API calls fail, which would make sense because the calls are being made to localhost.
Now, what would be the best approach to pass in machine-independent rest URLs? I do not want to set a static IP for my backend. I have tried:
Making a production build and bundling it with the backend. This again makes calls to localhost on the accessing machine, which fails.
Manipulating the URL with window.location.hostname+"getForm". This fails when I have different servers hosting frontend and backend.
Edit*
Okay, I managed to add a proxy to the node server by adding the following line to package.json.
"proxy":"http://localhost:8080/"
This forwards something like localhost:3000/api/getForm on the frontend to localhost:8080/api/getForm on the backend. This works pretty well, but now I am stuck on an issue which I presume is due to incorrect CORS setting. Proxied GET requests to the backend, which is a Spring Boot API, work fine, but proxied POST requests return a 403, with the response "Invalid CORS request".
I have added a #CrossOrigin(origins="http://localhost:3000") to the class-level of my spring application which should make all the apis CORS friendly. Also, I am using fetch on the frontend to make calls. Any leads on what I might be getting wrong?
POST /api/post HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Content-Length: 22
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Content-Type: application/json
Accept: /
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-IN,en-GB;q=0.9,en-US;q=0.8,en;q=0.7
Body - {"title":"abc","body":"def"}
Response - 403, Invalid CORS request
GET /api/get HTTP/1.1
Host: localhost:3000
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Accept: /
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-IN,en-GB;q=0.9,en-US;q=0.8,en;q=0.7
Response - 200, [{"id":1,"title":"Post 1","body":"Backend is connected fine and dandy!"}]
When you dont serve your code using node, you can use webpack to add globals, but then you need to create separate build for each environment.
When using Node with SSR:
What I usually do is use a .env file with specific constants for hostname, port, .. and use those in a js config file. Then you can import that js file and use it for your fetch calls. You can use dotenv (https://www.npmjs.com/package/dotenv) for adding the .env variables to your node process.
config file:
const config = {
env: {
host: (envConfig && envConfig.API_HOST) || 'localhost',
port: (envConfig && envConfig.API_PORT) || '8000',
httpOrigin: (envConfig && envConfig.API_PROTOCOL) || 'http'
}
}
export default config;
.env file:
API_PROTOCOL=https
API_HOST=localhost
API_PORT=8000
To transfer the config to the frontend you can seriablize in the the body of your html and pick it up on your client side render.
<script dangerouslySetInnerHTML={{ __html: `window.__envConfig=${serialize(envConfig)};` }} charSet="UTF-8"/>
I have an AngularJS web app that accesses a .NET WebAPI server end. Authentication is implemented through the AngularJS-OAuth2 library. I have the app and the WebAPI hosted in localhost under two different port numbers. I have also enabled Microsoft.Owin.Cors package on the server end to handle cross-domain requests.
In Chrome, GET and POST requests return data to the front-end. By inspecting the traffic through Fiddler I could see that a pair of requests/responses are sent (preflight/OPTIONS + actual) and also the relevant CORS headers (including origin and Access-Control-* headers) in both the requests and the responses. All as expected.
However, in Internet Explorer, my GET requests return data through the $http service but the POST does not. I could inspect that there are no preflight requests or CORS headers (I think IE treats different ports as the same origin). In checking the POST request/response in IE through Fiddler I could observe that it returns HTTP status 200 but state of Aborted (with X-ABORTED-WHEN: SendingResponse flag set). I could also inspect the JSON response with the correct data returned.
I have also tried setting a high timeout to no avail. The $http call looks like this:
return $http.post(apiUrl + "/search", service.getParameters(), { timeout: 600000 })
.success(function (data) {...
Fiddler shows something like this for the IE POST request:
Also (only) in IE, an unintentional page refresh is also triggered with the same button click as this POST operation.
Why does Internet Explorer abort only the POST requests when the correct data is also returned to the client and when Chrome does not have any issues at all?
Additional Information
Request:
POST https://localhost:44321/api//search HTTP/1.1
Content-Type: application/json;charset=utf-8
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: https://localhost:44322/search
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:44321
Content-Length: 202
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: .ASPXANONYMOUS=<cookie>
Reponse:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: <file>
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 13:43:45 GMT
Content-Length: 2284
Fiddler session properties:
SESSION STATE: Aborted.
Request Entity Size: 202 bytes.
Response Entity Size: 2284 bytes.
== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
X-ABORTED-WHEN: SendingResponse
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 41889
X-EGRESSPORT: 41890
X-HOSTIP: ::1
X-PROCESSINFO: avp:3584
X-RESPONSEBODYTRANSFERLENGTH: 2,284
X-SERVERSOCKET: REUSE ServerPipe#168
== TIMING INFO ============
ClientConnected: 19:13:42.408
ClientBeginRequest: 19:13:42.444
GotRequestHeaders: 19:13:42.444
ClientDoneRequest: 19:13:42.772
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 19:13:42.413
FiddlerBeginRequest: 19:13:42.772
ServerGotRequest: 19:13:42.772
ServerBeginResponse: 19:13:45.360
GotResponseHeaders: 19:13:45.360
ServerDoneResponse: 19:13:45.360
ClientBeginResponse: 19:13:45.360
ClientDoneResponse: 19:13:45.360
Overall Elapsed: 0:00:02.915
The response was buffered before delivery to the client.
== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.
I believe you get bitten by the P3P policy requirement of IE here:
Internet Explorer supports a cookie-restricting privacy feature called P3P. Web developers often get tripped up by it because no other browser implements the P3P standard.
It seems similar to those QAs:
CORS request with IE11
CORS doesn't work with cookies in IE10
Internet Explorer 10 is ignoring XMLHttpRequest 'xhr.withCredentials = true'
Here's a blog post with an example how to send P3P information. Here's a document from Microsoft about P3P configuration
What would cause Internet Explorer to replace the HTTP header
Authorization : Bearer <server-provided-token>
with
Authorization : Negotiate <some token>
when making an AJAX request?
Details
In Internet Explorer, some AJAX requests that are configured to contain the header Authorization: Bearer ... are being sent by Internet Explorer with the header Authorization: Negotiate ... instead.
For example, Fiddler shows that the first two of three requests contain the Authorization : Bearer... header, while the third suddenly contains the Authorization : Negotiate... header. The first two requests are successful, and the third fails because the request can't be properly authenticated.
All of the requests are constructed using the same client-side code, and are made one after another (within the span of a second). I have verified that the Authorization header correctly contains the Bearer token in all three cases up until the point the request is provided to the browser.
Also, I'm not seeing the same behavior in Chrome; it's only occurring in IE.
Request 1
GET http://localhost/myapp/api/User HTTP/1.1
Accept: application/json, text/plain, */*
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70
Referer: http://localhost/client/login.html
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost
DNT: 1
Connection: Keep-Alive
Request 2
POST http://localhost/myapp/api/Permissions HTTP/1.1
Referer: http://localhost/client/#/Dashboard
Content-Type: application/json
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70
Accept: application/json, text/plain, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost
Content-Length: 1419
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
<Post Data Removed>
Request 3
GET http://localhost/myapp/api/UserPreferences/Dashboard HTTP/1.1
Referer: http://localhost/client/#/Dashboard
Content-Type: application/json
Authorization: Negotiate YHsGBisGAQUFAqBxMG+gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHqI7BDlOVExNU1NQAAEAAACXsgjiBgAGADMAAAALAAsAKAAAAAYBsR0AAAAPVk1ERVZFTlYtU1JTQ0VSSVM=
Accept: application/json, text/plain, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive
DNT: 1
Host: localhost
The requests are being made via the AngularJS $http service, and the back-end is ASP.NET Web API hosted in IIS.
We had a problem where Internet Explorer was caching credentials. We could fix the problem by using the following script:
document.execCommand('ClearAuthenticationCache', 'false');
see: Wikipedia
I've just come across this issue too.
What was odd is that it worked fine on my development machine, it was when I deployed it the issue arose.
Again it worked fine in Chrome, Firefox etc.
It turns out that the issue is that IE was detecting the site was on the localintranet zone and was therefore trying to automatically trying log on (it was set by group policy - this is an internal app).
My workaround was that (luckily) it was only autodetecting local intranet zone when using a server name that wasn't an FQDN (e.g. myserver) - but using the full A
I had the same problem in a knockoutjs application, it worked fine in Chrome and Firefox but not in IE.
I also used Fiddler and noticed that the first ajax call used Bearer as intended and returned successfully. But then IE started to loop and send the subsequent ajax calls over and over again with the Negotiate authorization instead!
In my case it was some sort of timing issue in IE, I solved it by making the ajax calls that loaded data during rendering synchronous.
me.loadLimits = function () {
$.ajax({
type: 'GET',
dataType: 'json',
contentType: 'application/json',
url: '/api/workrate/limits',
headers: me.headers,
async: false,
success: function (result) {
...
I also encountered this issue when I was kicking off multiple data loads in my angular app.
I worked around this by detecting the browser and if IE, delayed each request by 50ms based on the index of the call:
return $q(function(resolve, reject) {
var delay = self.widget.useDelayLoading ? self.widget.index * 50 : 0;
setTimeout(function() {
restService.genericApi(self.widget.url, false).queryPost(json).$promise
.then(
function(r) { resolve(r); },
function(e) { reject(e); }
);
}, delay);
});
Interestingly, when I used $timeout, I had to increase the delay to 100ms.
We had faced similar issue with angular and web api. Issue happens when the system tries to access some resource at root level which had Windows Authentication enabled. In our case, application was trying to get the favicon from IIS root. Once this request gets unauthorized, IE will try getting the resouce with negotiation header; though it fails again. But from this point onwards, IE keep sending negotiate header instead of our bearer token. This is due to the settings in IE, which I think is in Internet Options -> Advanced tab -> Enable Integrated Windows Authentication in the Security section (not sure, I forgot the exact stuff).
Fix was either give anonymous access to root level or to the resource location which app is trying to access (bad option) or have document.execCommand('ClearAuthenticationCache', false); in the app.js file.
In my case, IE alternated between sending a bad request, followed by a good request on a second attempt, then followed by a bad request again and so on.
After trying several approaches to causing IE to retry - it appears that returning a 307 (Temporary redirect) with the same request url in the Location header solves the issue.
e.g. for a request to "http://myUrl/api/service/"
HTTP 307 Temporary Redirect
Location: http://myUrl/api/service/
IE retries the call with the proper data.
Edit: This method might be dangerous as it might create an infinite loop. A possible solution to work around it, is to return some counter as part of the url in the Location header and analyze it when receiving the call again.