Cross-Origin Request Blocked in Firefox only! [OPTIONS : 403 Forbidden] - amazon-web-services

It's a CORS problem again
[and I don't have much knowledge about CORS].
My environment :
I have JSON file stored in Amazon S3 server, and reading this JSON file from my web application.
My issue :
I am getting this in FireFox only
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at server. (Reason: CORS header
‘Access-Control-Allow-Origin’ missing)
Note : I have configured CORSRule in the server [Amazon S3]; after that, Chrome and other browsers work properly, but Firefox gives this error.
In Firefox Network tab [inspect element]:
Status : 403
Method : OPTIONS
Cause : xhr
Type : xml
Request Headers :
Host: myWebApp.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/plain, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Referer: https://myWebApp.net/page.jsp
Connection: keep-alive
Response Headers :
Content-Length: 0
Date: Thu, 24 Nov 2016 07:27:30 GMT
Location: https://webApp.s3.amazonaws.com/file.json
Server: Apache-Coyote/1.1
I have looked around but didn't find any causes.
So I need your help.
As it works properly in the Chrome browser, the issue is in Firefox only.
Please describe step by step if possible [I am new to these things].

Opps!
Finally got solution.
The issue was in Amazon S3's CORSConfiguration
I don't know much about it, but now its allowing Cross-Origin from all browsers.
I have changes CORSConfiguration as :
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>https://myWebApp.net</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
<ExposeHeader>x-amz-request-id</ExposeHeader>
<ExposeHeader>x-amz-id-2</ExposeHeader>
</CORSRule>
</CORSConfiguration>
by this rules, browsers getting proper Request Headers and Response Headers.
Request Headers :
Host: myWebApp.s3.amazonaws.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.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, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-requested-with
origin: https://myWebApp.net
Connection: keep-alive
Cache-Control: max-age=0
Response Headers :
Access-Control-Allow-Headers: x-requested-with
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Origin: https://myWebApp.net
Access-Control-Max-Age: 3000
Content-Length: 0
Date: Thu, 24 Nov 2016 13:21:17 GMT
Server: AmazonS3
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
access-control-allow-credentials: true
access-control-expose-headers: x-amz-server-side-encryption, x-amz-request-id, x-amz-id-2
x-amz-id-2: emYYMILNIdkCejpjuDXz4Haks87asdhj/7JL5AASt/8eIwKdgO1Gb/AzGRg7SU/GH55IVopScg=
x-amz-request-id: 307572CDFF39F443

Related

POST request returning 401 Unauthorised (only in Chrome)

I'm using Django Rest Framework and Vue.js to build a basic web app, and am currently working on the auth. Using axios to send a post request while registering a new user returns 401 in Chrome for some reason, but works in other browsers (Edge) and returns a 201 Created.
The error in chrome is "detail: Invalid Token", but this particular endpoint (registration) doesn't even need auth/token to access.
My frontend is at http://192.168.1.33:8080 and my backend is at http://127.0.0.1:8000
I am trying to POST data to http://127.0.0.1:8000/api/v1/users/auths/
The Network tab in chrome dev tools after trying a request:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 401 Unauthorized
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 27
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:19:15 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin
WWW-Authenticate: Token
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Token acf8b9099de5eba413dea141ce2c06b6cfb03159
Connection: keep-alive
Content-Length: 53
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
The network tab in Edge dev tools after trying the same thing:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 201 Created
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 89
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:20:25 GMT
Location: http://127.0.0.1:8000/api/v1/users/auths/12/
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin, Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization
Connection: keep-alive
Content-Length: 51
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Microsoft Edge";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36 Edg/96.0.1054.43
The obvious difference is that there is a "WWW-Authenticate: Token" in the Chrome Network tab, which is odd.
CORS headers and all have been set up properly, plus the issue is only in Chrome. Is this some Chrome quirk, or am I missing something?
Why is it that, after spending some two hours on a problem, you only get the answer after you've posted it on a forum? Probably something to do with putting the problem down categorically and formally...
Anyway. Turns out the issue was with there being a random token sitting in Chrome's local storage, which was causing all the trouble with the "invalid" token. I cleared local storage, and it's working now. No clue why I had to do this specifically — I had made sure to clear the cache earlier...

CORS issue working with DJango Simple SSO

I'm using a fork of Django Simple SSO as an authentication mechanism on a Server.
It works great while we use the "standard" way to log in on the server. This means, we just access to the /login path, log in, and then navigate across the restricted paths, etc.
The problem comes when we want to connect to a 3rd server that also relays on SSO auth vía javascript/AJAX without direct access to /login path first.
I've tried to use django-cors-headers but didn't get the expected result.
I'm close to give up so any help is welcome.
The problem
Assume we are logged in on server 1 and auth server and we want a resource on server 2
When the browser is redirected to the Auth Server in order to verify that the browser is logged with a valid user, the cookie header is not transferred.
(See the diagram on button for further details on how Django Simple SSO works)
The headers set by the auth-server on the preflight request are the following:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept-encoding, accept, authorization, cookie, content-type, dnt, origin, user-agent, x-csrftoken, x-grafana-org-id, x-dashboard-id, x-panel-id, x-requested-with
Access-Control-Allow-Methods: DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin: https://server1-domain
Access-Control-Max-Age: 86400
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Jul 2021 12:14:54 GMT
Server: nginx
Vary: Origin
The headers on the GET request where the following:
Request/Client:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: es-ES,es;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Host: auth-server-domain
Origin: https://server1-domain
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
x-grafana-org-id: 1
Response/Auth Server:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://server1-domain
Connection: keep-alive
Content-Language: es
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Jul 2021 12:14:54 GMT
Location: /error_unauthorized_page
Referrer-Policy: same-origin
Server: nginx
Vary: Accept-Language, Cookie, Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
I think all the headers are correct, but it's clearly there are some error.
On the cookie side, I have tried to play with the SingleSite property, setting it to None and Lax without any change.
The domain set on the cookie browser's memory is "correct" from my point of view as it is .auth-server-domain (note the dot).
I'm using DJango 3.2.5 and Google Chrome as a web browser.
If you have any idea of why cookie is not being send on the auth-server-domain cors requests, I will really appreciate your comments.
If do you think I have missed any piece of relevant information, feel free to ask!
Thank everyone to reach this point and help me!
Appendix:
A simplified schema of how Simple SSO works:

Unable to decode CORS gzipped content from EC2 via Cloudfront

This is probablly related to Serving gzipped CSS and JavaScript from Amazon CloudFront via S3, but although I followed the doc I still can get this situation to work :
An S3 bucket contains files that I have gzipped (with grunt-contrib-compress, if that's of any relevance.)
My bucket has a CORS configuration :
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*.myorigin.net</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
The bucket is served via Cloudfront.
My Cloudfront has CORS configured to :
Allow GET,HEAD,OPTIONS,PUT,etc...
on HTTPS
to cache OPTIONS requests
to whitelist Access-Control-Request-Headers, Access-Control-Request-Method and Origin
Using curl, I'm able to get my resources, with the right header to request gzip, and I get a gzipped version
curl --insecure https:/whatever.cloudfront.net/.../foo.js --silent -H "Accept-Encoding:gzip,deflate,sdch" -I
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 33990
Connection: keep-alive
Date: Wed, 06 May 2015 17:12:53 GMT
Content-Encoding: gzip
Last-Modified: Wed, 06 May 2015 16:36:40 GMT
ETag: "7a92919df6117827de9474851afe06c0"
Accept-Ranges: bytes
Server: AmazonS3
Age: 70
X-Cache: Hit from cloudfront
Via: 1.1 (redacted).cloudfront.net (CloudFront)
X-Amz-Cf-Id: iaghGGDg3f3l4njz7mpXeOzqIS5OCR5kaehk4Td4-Bxiv2KtljHVlQ==
I'am able to get the content decoded by adding the --compressed flag, so the files seem to be correct.
If I now do a CORS request, with curl, again, I get the proper encoding :
curl --insecure https://.../foo.js --silent -H "Accept-Encoding: gzip,deflate,sdch" -I -H "Origin: myorigin.net"
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 33990
Connection: keep-alive
Date: Wed, 06 May 2015 17:16:06 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD
Access-Control-Max-Age: 3000
Content-Encoding: gzip
Last-Modified: Wed, 06 May 2015 16:36:40 GMT
ETag: "7a92919df6117827de9474851afe06c0"
Accept-Ranges: bytes
Server: AmazonS3
Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method
X-Cache: Miss from cloudfront
Via: 1.1 redacted.cloudfront.net (CloudFront)
X-Amz-Cf-Id: kaUV4S9wiCGzXp8N_Gg2LhGK8uYw1-qRtSw6w_Ry4V8oHZiLRvWULA==
Still, for some reason, when my browser does the request... there is no "Content-Encoding", and so the content is not uncompressed, and since I'm loading it with requirejs, I get a bad error.
Request :
GET /resources-gz/foo.js HTTP/1.1
Host: d28p9e2ugw1o8w.cloudfront.net
Connection: keep-alive
Cache-Control: no-cache
Accept: */*
Pragma: no-cache
User-Agent: Mozilla/5.0 (X11; Linux i686 (x86_64)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Referer: http://localhost:3000/start
Accept-Encoding: gzip,deflate,sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4,de;q=0.2
Response:
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 33990
Connection: keep-alive
Date: Wed, 06 May 2015 16:31:27 GMT
Last-Modified: Wed, 06 May 2015 14:36:32 GMT
ETag: "7a92919df6117827de9474851afe06c0"
Accept-Ranges: bytes
Server: AmazonS3
Age: 1261
X-Cache: Hit from cloudfront
Via: 1.1 eazeaze.cloudfront.net (CloudFront)
X-Amz-Cf-Id: IjpNd37e-c38Moz3HQJ940KNTXfp1NN7O4enQJUYPd6Aet5Egw8XPg==
I'm obviously missing something...
Yes, you're missing something.
Read the response headers of the last response.
Last-Modified: Wed, 06 May 2015 14:36:32 GMT
ETag: "7a92919df6117827de9474851afe06c0"
Age: 1261
X-Cache: Hit from cloudfront
This is a CloudFront cache hit, and CloudFront fetched this object from S3 20+ minutes before you requested it ... and this version of the object had last been modified in S3 over two hours earlier... so, you're getting a copy that probably dates from before you "fixed" whatever you recently fixed.
When the etag of an object doesn't change, that means the body has not changed... but it doesn't imply anything about the response headers.
The easiest way to test this is to put a new file in S3 with a name you haven't used before... gzipped, of course, then try downloading it again.

simple javascript file keeps returning 301 with cloudfront

I'm using cloudfront for a simple javascript asset that is the following:
https://d1syjrf5lltxmn.cloudfront.net/Content/JavaScript/jquery-migrate-1.2.1.min.js
I've got the Origin Domain name and path set to
www.siliconvalley-codecamp.com
Origin type is custom origin, policy i sMatch Viewer, view policy is http and https. Problem is when it hit this (over and over) it keeps returning a 301 and doing another request from my origin server.
I can't figure out why it keeps doing the 301's. I've read others having issues but can not find a solution.
GET https://d1syjrf5lltxmn.cloudfront.net/Content/JavaScript/jquery-migrate- 1.2.1.min.js HTTP/1.1
Host: d1syjrf5lltxmn.cloudfront.net
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
and the return is:
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Content-Length: 208
Connection: keep-alive
Location: https://www.siliconvalley-codecamp.com/Content/JavaScript/jquery-migrate-1.2.1.min.js
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 23 Jan 2015 04:18:21 GMT
Age: 10575
X-Cache: Hit from cloudfront
Via: 1.1 f86dab587205f74a0e6f36b42207dec2.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 8h4R0WTOl1wg8LDafMoeAkcvOr1G8ujfAVMgz84Uy_BVE8QlxTbTrQ==
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found here</body>
Origin server setup:

Why doesn't Jayrock (.NET JSON-RPC Framework) like my request?

Hi quick question about Jayrock... I have a Jayrock JSON-RPC web service that generally works fine. However, when I try to post to my jqGrid editUrl, Jayrock throws an error. The web service works fine in other situations.
Anyone have a clue why Jayrock doesn't like the following request? Perhaps a way to configure Jayrock to accept this request?
Request:
POST
/StoryManager/StoryManager.ashx/setPageItemRoles
HTTP/1.1
Host: localhost:2064
User-Agent: Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.9.1)
Gecko/20090624 Firefox/3.5 (.NET CLR
3.5.30729)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type:
application/x-www-form-urlencoded;
charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer:
http://localhost:2064/StoryManager/PageItemDetail.aspx
Content-Length: 183
Cookie:
ASP.NET_SessionId=uycy1qmowzzqhiac1kg3e455
Pragma: no-cache
Cache-Control: no-cache
title=Narrative&assignedto=dfghdfgh&assigned=2009-06-25T14%3A52%3A24.0868931-05%3A00&due=2009-08-02T14%3A52%3A24.0868931-05%3A00&completed=2009-07-17T14%3A52%3A24.0868931-05%3A00&id=3
Response:
{"id":null,"error":{"name":"JSONRPCError","message":"Found
String where Object was
expected.","stackTrace":" at
Jayrock.Json.JsonReader.ReadToken(JsonTokenClass
token) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock.Json\Json\JsonReader.cs:line
142\r\n at
Jayrock.JsonRpc.JsonRpcDispatcher.ParseRequest(TextReader
input) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock\JsonRpc\JsonRpcDispatcher.cs:line
271\r\n at
Jayrock.JsonRpc.JsonRpcDispatcher.Process(TextReader
input, TextWriter output) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock\JsonRpc\JsonRpcDispatcher.cs:line
127","errors":[{"name":"JsonException","message":"Found
String where Object was expected."}]}}
Because you send application/x-www-form-urlencoded request with "form-like" post data instead of application/json with correct json object.