I have hosted my web-app on "Firebase Hosting" on my own custom domain for eg:- webapp.example.com. I have enabled CORS so that browser wont block it.
My REST services are hosted on another sub-domain eg:- api.example.com
Now when I am calling API from my web-app it says "Failed to load response" and fails.
Status code is 200 though.
Response Headers:
Access-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept
Access-Control-Allow-Methods: POST,GET,PUT,OPTIONS,DELETE,PATCH
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 3600
Allow: GET, HEAD, POST, TRACE, OPTIONS
Connection: close
Content-Length: 0
Date: Sun, 28 Apr 2019 09:37:30 GMT
Server: Apache-Coyote/1.1
Request Headers
Access-Control-Request-Headers: content-type,x-referral
Access-Control-Request-Method: GET
Origin: https://webapp.example.com
Referer: https://webapp.example.com/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Any idea why this is happening or how should I fix it.
Related
Running into an issue with CORS and redirect, here is the simplified flow:
Browser ---> K8 NGINX Ingress Controller ---> Service
|
|
Oauth Proxy
From Chrome developer tools: Preflight
General:
Request URL: https://yyyy
Request Method: OPTIONS
Status Code: 204
Remote Address: x.x.x.x:443
Referrer Policy: strict-origin-when-cross-origin
Request headers Preflight
:authority: yyyy
:method: OPTIONS
:path: /api
:scheme: https
accept:*/*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
access-control-request-headers: x-requested-with
access-control-request-method: GET
cache-control: no-cache
origin: https://xxxx
pragma: no-cache
referer: https://xxxx
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
Response Headers: Preflight
access-control-allow-credentials: true
access-control-allow-headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization
access-control-allow-methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
access-control-allow-origin: https://xxx
access-control-max-age: 1728000
content-length: 0
date: Mon, 06 Feb 2023 13:47:36 GMT strict-transport-security: max-age=15724800; includeSubDomains
Original Request: Headers
:authority: yyyy
:method: GET
:path: /api
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache origin: https://xxxx
pragma: no-cache
referer: https://xxxx
sec-ch-ua: "Not?A_Brand";v="8", "Chromium";v="108", "Google Chrome";v="108"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 x-requested-with: XMLHttpRequest
General
Request URL: https://yyy/a/api/a/a?=abc
Request Method: GET
Status Code: 302
Referrer Policy: strict-origin-when-cross-origin
Response Headers:
content-length: 138
content-type: text/html
date: Mon, 06 Feb 2023 13:47:36 GMT
location: https://yyyy/oauth2/start?rd=%2Fa%2Fapi%2Fs%2Fb%3Fx%3D1
Browser Blocks:
Access to XMLHttpRequest at 'https://yyyy from origin 'https://xxxx has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource
Steps taken so far:
Read many SO questions for a match including this:
Chrome cancels CORS XHR upon HTTP 302 redirect
The way I understand this article: https://github.com/monmohan/cors-tutorial-practical/tree/master/issue
is that if the CORS request redirect with 3XX, then the browser should follow the redirect, but that is not happening
Read Mozilla docs:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
Tried to follow this three part blog series and its associated github exercise:
https://software-factotum.medium.com/cross-origin-resource-sharing-a-hands-on-tutorial-fb19748cb3b7
The sequence when making a preflighted request to a URL that gets a redirect response is:
The browser makes a preflight OPTIONS request to A
The server must respond with CORS permission
The browser makes the real request to A
The server must respond with CORS permission and the redirect directive to B
The browser makes a preflight OPTIONS request to B
The server must respond with CORS permission
The browser makes the real request to B
The server must response with CORS permission and the data
It isn't entirely clear from your examples, but your sequence appears to be failing at step 4, where you are responding with the redirect directive but without CORS permission.
I'm trying to develop with universal deep links. When the user has the Uber app installed, everything works as expected. But if not, the user ends up at a page with "Open in the Uber app" and "Download Uber" links, both of which do nothing. In the console, a CORS error is reported. This includes opening the "example universal deep link to Uber HQ" given in the developer docs. Is this a known issue or is there something I can do to work around it? I'd like my users to be able to use the deep link without this poor experience.
Request headers (for ul-min.a36a5e.js):
GET /web-mobile-client/js/ul-min.a36a5e.js HTTP/1.1
Host: d34odocr7rsfu1.cloudfront.net
Connection: keep-alive
Origin: https://m.uber.com
Sec-Fetch-Dest: script
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; Moto Z (2)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.99 Mobile Safari/537.36
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Referer: https://m.uber.com/ul/?action=setPickup&pickup=my_location&dropoff%5Bformatted_address%5D=Uber%20HQ%2C%20Market%20Street%2C%20San%20Francisco%2C%20CA%2C%20USA&dropoff%5Blatitude%5D=37.775231&dropoff%5Blongitude%5D=-122.417528&_ga=2.28187893.830846417.1581952272-1919070024.1581952272
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ja;q=0.8
Response Headers
HTTP/1.1 403 Forbidden
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Date: Tue, 18 Feb 2020 17:29:53 GMT
Server: AmazonS3
X-Cache: Error from cloudfront
Via: 1.1 c66a9c8f31dcbd61d052f66d50b6d87c.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: LAX3-C1
X-Amz-Cf-Id: 00Y21qP41BPYaywzR6BHA0BC-5ctAe03xFKBgOBgDKupwlaN-2IzLA==
I am getting a weird behavior from Chrome, which I was not recently getting. A week ago, my project was making proper CORS requests to my REST api (Java spring) and all was fine. But yesterday, Chrome (59.0.3071.115) is no longer sending the JSESSIONID as it used to. It now sends a io cookie in its place. That io cookie seems related to WebSocket in some way, which I am not making use of in any of my code.
The thing is, when I try the same code on Edge browser, everything is fine. Edge does send my JSESSIONID cookie and no "io" cookie is sent.
Anyone has experienced this before?
Here is my setup and an example of a request on both browsers.
Setup:
OS: Windows 10
SPA: React, AXIOS (0.16.2)
REST: Java, Spring boot, Tomcat (Embedded)
AXIOS configuration
function getNewAxiosInstance() {
//Init our instance
const ax = axios.create();
//Config defaults
ax.defaults.baseURL = rootUri;
ax.defaults.timeout = 1000;
ax.defaults.withCredentials = true;
return ax;
}
Chrome request
Request URL:http://localhost:8080/api/2.0/client/service_orders/_activeState
Request Method:GET
Status Code:200
Remote Address:[::1]:8080
Referrer Policy:no-referrer-when-downgrade
Response Headers
view source
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:3000
Content-Type:application/json;charset=UTF-8
Date:Sun, 16 Jul 2017 13:58:39 GMT
Set-Cookie:JSESSIONID=6DA824C819AB48051DC6A63367010DDA;path=/;HttpOnly
Transfer-Encoding:chunked
Vary:Origin
Request Headers
view source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8,fr-CA;q=0.6,fr;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:io=T6umtNN53FTADnx1AAAA
Host:localhost:8080
Origin:http://localhost:3000
Pragma:no-cache
Referer:http://localhost:3000/
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Edge request
Request URL: http://localhost:8080/api/2.0/reception/service-orders/_activeState
Request Method: GET
Status Code: 200 /
- Request Headers
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-CA
Connection: Keep-Alive
Cookie: JSESSIONID=177FD4191C578793F8BC04D9DB7287A5
Host: localhost:8080
Origin: http://localhost:3000
Referer: http://localhost:3000/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063
- Response Headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:3000
Content-Type: application/json; charset=UTF-8
Date: Sun, 16 Jul 2017 14:08:26 GMT
Transfer-Encoding: chunked
Vary: Origin
Oh well,
There was indeed something fishy with Chrome. I just reinstalled Chrome from scratch and all is good.
Don't know what happened with Chrome, as I did not install any new extensions nor did I changed any settings.
Cheers
I am new to REST so bear with me if I'm missing something obvious.
Any pointer would be much appreciated as I am a bit lost.
Scenario
I needed to post some data to the following REST service: https://api.dotmailer.com/ from my web application https://myapp.com/.
During testing, I was able to post the data from my local pc.
However, as soon as I published the updated application to https://myapp.com/ on a remote server, I was no longer able to post any data.
What I've tried so far
Added rule to the remote server firewall to allow outgoing traffic to use https. Didn't solve the problem.
Disabled the url rewriting rule that change http to https for myapp.com. Didn't solve the problem.
Pasted the URL I use to post my data (https://api.dotmailer.com/v2/address-books/12345/contacts) in a browser on the remote server, entered the correct credentials, but couldn't access it.
the error message said "Unable to open this internet site. The requested site is either unavailable or cannot be found." If I do the same on my local PC I can access the URL.
Monitored the two calls with Fiddler2.
I include the results of the monitoring process below:
CALLS MADE FROM REMOTE SERVER
----------
POST /bla.aspx HTTP/1.1
Host: myapp.com
Connection: keep-alive
Content-Length: 10660
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://myapp.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: https://myapp.com/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
CALLS MADE FROM LOCAL PC
----------
POST /bla.aspx HTTP/1.1
Host: localhost:xxx
Connection: keep-alive
Content-Length: 10656
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:60675
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: http://localhost:xxx/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: __eqtUser=xxx; ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
Question
I believe point 3 shows that the cause is some setting on the remote server.
Does anyone know what it could be? Or am I completely off-track?
Update
I spoke with the developer on the receiving end of my calls who can monitor incoming traffic.
He could see my local calls but not the ones submitted from https://myapp.com.
In response to gmlime reply, I've added the following to myapp.com web.config file but didn't help.
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
Should I put it at a higher level in the hierarchy?
Make sure that this gets added to the response:
YourAddHeaderMethod("Access-Control-Allow-Origin", "*");
Many servers deny posting from other domains and can terminate the connection. You can learn more about it from the w3 docs for Access-Conrol-Allow-Origin and Mozzilla covers some scenarios. You may have to check with the server administrator to rule out cross domain problems also.
I have a small site where I have a mailing list contact form in an iFrame, and once its submitted, a callback page I registered with the mailing list service is called, displaying in the iFrame and asking the user to check their email. The page I registered is http://mydomain.com/verify.html. In vertify.html I use "window.parent.document.getElementById('lightbox4').style.display='none';" to close the lightbox div that contains the I frame. This all works well, as long as the user initially visits http://mydomain.com, but if they visit http://www.mydomain.com, then calling "window.parent.document.getElementById('lightbox4').style.display='none';" doesn't work, because its a cross domain request.
So, no problem I thought, I'll just create a redirect rule to convert calls from www.mydomain.com, to mydomain.com. But now I'm getting the error "This webpage has a redirect loop" when I try to go to either www.mydomain.com or mydomain.com. In IIS7, I have two bindings, one for mydomain.com and one for www.mydomain.com. My DNS zone has an A record for mydomain.com, and a CNAME for www.mydomain.com.
Am I doing something stupid here? Is there ome way to debug this? I can see in Firefox, using the Live HTTP headers plugin, the URL is redirected properly from www.mydomain.com to mydomain.com , but then tries to keep trying to redirect mydomain.com to mydomain.com, creating the endless loop:
http://www.mydomain.com/
GET / HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.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
HTTP/1.1 302 Redirect
Content-Type: text/html; charset=UTF-8
Location: http://mydomain.com/
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sun, 21 Apr 2013 15:20:12 GMT
Content-Length: 150
----------------------------------------------------------
http://mydomain.com/
GET / HTTP/1.1
Host: mydomain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.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
HTTP/1.1 302 Redirect
Content-Type: text/html; charset=UTF-8
Location: http://mydomain.com/
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sun, 21 Apr 2013 15:20:12 GMT
Content-Length: 150
----------------------------------------------------------
http://mydomain.com/
GET / HTTP/1.1
Host: mydomain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.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
HTTP/1.1 302 Redirect
Content-Type: text/html; charset=UTF-8
Location: http://mydomain.com/
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sun, 21 Apr 2013 15:20:12 GMT
Content-Length: 150
----------------------------------------------------------
and it keeps going until "This webpage has a redirect loop" is displayed
I expect I have to create a new virtual directory for www.mydomain.com and then redirect that to mydomain.com, but that seems awkward.