hls.js CORS using AWS Cloudfront issues with Cookies - cookies

I'm trying to set up a video streaming using Cloudfront HLS capabilities but I'm having trouble getting Hls.js to send my credential cookies in the request.
I already have Cloudfront configured to forward cookies and to forward Access-control headers. I also have set my S3 CORS policies to include GET, HEAD.
The problem I'm having is that even though I'm setting the xhr.withCredentials=true and the cookies are defined in the session, when I look at the request using chrome console, I can see that the HLS request has no cookies. As a result I get an error response from cloudfront saying I need to include the credential cookies.
Code:
First I do an ajax request to my server to generate the cookies. The server returns three Set-Cookies headers stored as session cookies in the browser:
$.ajax(
{
type: 'GET',
url: 'http://subdomain.mydomain.com:8080/service-
webapp/rest/resourceurl/cookies/98400738-a415-4e32-898c-9592d48d1ad7',
success: function (data) {
playMyVideo();
},
headers: { "Authorization": 'Bearer XXXXXX' }
});
Once the cookies are stored the test function is called to play my video using HLS.js:
function test(){
if (Hls.isSupported()) {
var video = document.getElementById('video');
var config = {
debug: true,
xhrSetup: function (xhr,url) {
xhr.withCredentials = true; // do send cookie
xhr.setRequestHeader("Access-Control-Allow-Headers","Content-Type, Accept, X-Requested-With");
xhr.setRequestHeader("Access-Control-Allow-Origin","http://sybdomain.domain.com:8080");
xhr.setRequestHeader("Access-Control-Allow-Credentials","true");
}
};
var hls = new Hls(config);
// bind them together
hls.attachMedia(video);
hls.on(Hls.Events.MEDIA_ATTACHED, function () {
console.log("video and hls.js are now bound together !");
hls.loadSource("http://cloudfrontDomain.net/small.m3u8");
hls.on(Hls.Events.MANIFEST_PARSED, function (event, data) {
console.log("manifest loaded, found " + data.levels.length + " quality level");
});
});
}
video.play();
}
As you can see below HLS OPTIONS and GET request do not set the session cookies:
HLS OPTIONS request:
OPTIONS /hls/98400738-a415-4e32-898c-9592d48d1ad7/small.m3u8 HTTP/1.1
Host: cloudfrontDomain.net
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: subdomain.mydomain.com:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36
Access-Control-Request-Headers: access-control-allow-credentials,access-control-allow-headers,access-control-allow-origin
Accept: */*
Referer: http://subdomain.mydomain.com:8080/play.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,es;q=0.6
CloudFront response:
HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Date: Fri, 07 Jul 2017 00:16:31 GMT
Access-Control-Allow-Origin: http://subdomain.mydomain.com:8080
Access-Control-Allow-Methods: GET, HEAD
Access-Control-Allow-Headers: access-control-allow-credentials, access-control-allow-headers, access-control-allow-origin
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Server: AmazonS3
Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method
Age: 845
X-Cache: Hit from cloudfront
Via: 1.1 cloudfrontDomain.net (CloudFront)
X-Amz-Cf-Id: XXXXXX
HLS subsequent GET request missing the cookies:
GET /hls/98400738-a415-4e32-898c-9592d48d1ad7/small.m3u8 HTTP/1.1
Host: cloudfrontDomain.net
Connection: keep-alive
Origin: http://subdomain.mydomain.com:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36
Access-Control-Allow-Origin: http://subdomain.mydomain.com:8080
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Accept, X-Requested-With
Accept: */*
Referer: http://subdomain.mydomain.com:8080/play.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,es;q=0.6
I've spent 4 days trying to figure this out. I've done plenty of research but I just can't figure out the solution. I'm new to CORS so maybe I'm not understanding some principle. I thought if the cookies are stored in the session they would get set if you enabled xhr with credentials but it doesn't seem to be the case.
Another thing I noted is that the GET request generated by HLS.js is not setting any xmlhttprequest header.
Thanks for your help :)

I was finally able to make it work. Thanks Michael for helping! Turns out it was a mix of not understanding how CORS principles work and properly configuring aws services. The main issue is to avoid cross domain requests by using cloudfront to serve both your webservice and s3 bucket. One important note I want to add is that any change you make in aws you have to wait for it to propagate. As a new aws dev I didn't know that and got very frustrated making changes that had no effect. Here is the solution:
1) Create your S3 bucket.
2) Create a Cloudfront distribution.
3) In the distribution set as the default origin your web-service domain.
4) Add a second origin and add a behavior in the distribution to forward all .m3u8 and .ts files to your S3 bucket.
5) When you add your bucket origin make sure you mark restrict access and also update bucket policy checkboxes.
6) In your bucket distribution behavior make sure you forward all white list headers and cookies. This can all be set in aws console.
7) If you are using different ports in your service make sure you set those too in the distribution.
8) Go to your S3 bucket settings and update the CORS config to the following:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
It is important that if your are using HLS.js to set the following config:
var config = {
debug: true,
xhrSetup: function (xhr,url) {
xhr.withCredentials = true; // do send cookie
xhr.setRequestHeader("Access-Control-Allow-Headers","Content-Type, Accept, X-Requested-With");
xhr.setRequestHeader("Access-Control-Allow-Origin","http://sybdomain.domain.com:8080");
xhr.setRequestHeader("Access-Control-Allow-Credentials","true");
}
};
var hls = new Hls(config);
Other important notes:
When you serve a cookie with your web service you can set the Path to be "/" and it will apply to all request in your domain.

For anyone that might be having this issue only on Chrome for Android, our problem was that the browser was caching the m3u8 files and giving the same CORS error. The solution was to append a timestamp parameter to the querystring of the file url:
var config = {
xhrSetup: function (xhr, url) {
xhr.withCredentials = true; // do send cookies
url = url + '?t=' + new Date().getTime();
xhr.open('GET', url, true);
}
};
var hls = new Hls(config);

Related

Canonical Request to AWS Signature 4 is correct?

I'd like to ask if there's any error in my canonical request, im trying to create one to the AWS Secrets Manager taking the sample request by example.
Doc:https://docs.aws.amazon.com/pt_br/AmazonS3/latest/API/sig-v4-header-based-auth.html
Sample Request:
`POST / HTTP/1.1
Host: secretsmanager.region.domain
Accept-Encoding: identity
X-Amz-Target: secretsmanager.GetSecretValue
Content-Type: application/x-amz-json-1.1
User-Agent:
X-Amz-Date:
Authorization: AWS4-HMAC-SHA256 Credential=,SignedHeaders=, Signature=
Content-Length:
{
"SecretId": "MyTestDatabaseSecret",
}`
My Canonical Request:
`POST
/GetSecretValue
accept-encoding:identity
content-type:application/x-amz-json-1.1
host:secretsmanager.sa-east-1.amazonaws.com
x-amz-content-sha256:beaead3198f7da1e70d03ab969765e0821b24fc913697e929e726aeaebf0eba3
x-amz-date:20230111T145646Z
x-amz-target:secretsmanager.getsecretvalue
accept-encoding;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-target
beaead3198f7da1e70d03ab969765e0821b24fc913697e929e726aeaebf0eba3`
I did the changes that the documentation was asking, but when i try to recreate the signature by the postman, well, It gets wrong.

Add X-Frame-Options header to all URLs using CloudFront functions

I have a single page application and I'm trying to prevent clickjacking by adding X-Frame-Options header to the HTML responses. My website is hosted on S3 through CloudFront.
The CloudFront distribution is configured to send index.html by default:
Default root object
index.html
In the Error Pages section I configured 404 page to also point to the index.html. This way all URLs that are not in S3 return the default HTML, i.e. /login, /admin etc.
Update The 403 status code is also configured:
Then I have created a CloudFront function as described here and assigned it to the Viewer response:
function handler(event) {
var response = event.response;
var headers = response.headers;
headers['x-frame-options'] = {value: 'DENY'};
return response;
}
This works, but only for /:
curl -v https://<MYSITE.com>
....
< x-frame-options: DENY
For other URLs it doesn't work - the x-frame-options header is missing:
curl -v https://<MYSITE.com>/login
....
< x-cache: Error from cloudfront
My question is - why my cloudfront function does not append a header in the error response, and what can I do to add it?
I understand that your questions are:
Q1: Why does the CloudFront function work for /?
Q2: Why doesn't the CloudFront function work for other url path?
Please refer to the responses below:
A1: Since you might specify a Default Root Object [1] (e.g.index.html) which returning the object when a user requests the root URL. When CloudFront returns the object with 200 ok, the CloudFront Function will be invoked on the viewer response event.
A2: You might not give the s3:ListBucket permissions in your S3 bucket policy(e.g. OAI). As the result, you will get Access Denied(403) errors for missing objects instead of 404 Not Found errors. Namely, the Error Pages you have configured isn't applied to this case, and the CloudFront Function won't be invoked because the HTTP status code is higher than 399[2].
[Updated] Suggestion:
Since CloudFront does not invoke edge functions for viewer response events when the origin returns HTTP status code 400 or higher. However, Lambda#Edge functions for origin response events are invoked for all origin responses. In this senario, I'll suggest that we should use Lambda#Edge instead of CloudFront Functions.
For your convenience, please refer to the sample code of l#e:
exports.handler = async (event, context) => {
const response = event.Records[0].cf.response;
const headers = response.headers;
headers['x-frame-options'] = [{
key: 'X-Frame-Options',
value: 'DENY',
}];
return response;
};
FYI. Here is my curl test result:
# PATH: `/`
$ curl -sSL -D - https://dxxxxxxx.cloudfront.net/
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12
Connection: keep-alive
ETag: "e59ff97941044f85df5297e1c302d260"
___snipped___
Server: AmazonS3
X-Frame-Options: DENY
___snipped___
# PATH: `/login`
$ curl -sSL -D - https://dxxxxxxx.cloudfront.net/login
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12
Connection: keep-alive
ETag: "e59ff97941044f85df5297e1c302d260"
___snipped___
Server: AmazonS3
X-Frame-Options: DENY
___snipped___

CORS on AWS API Gateway and S3

I am calling an AWS API which uses lambda function. I am calling it from a HTML page which is hosted in S3 (static web hosting). While calling the API I get CORS error:
Access to XMLHttpRequest at '' from origin
'' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource.
I have tried it after enabling CORS on API, Specifying CORS on S3 bucket but it is not working.
Seems, I am missing the right place where CORS headers are to be specifies.
Additional information:
I get following information in chrome developer tool
**Response Headers**
content-length: 42
content-type: application/json
date: Mon, 24 Feb 2020 04:28:51 GMT
status: 403
x-amz-apigw-id: IYmYgFQvoAMFy6Q=
x-amzn-errortype: MissingAuthenticationTokenException
x-amzn-requestid: 79b18379-383d-4ddb-a061-77f55b5727c3
**Request Headers**
authority: apiid-api.us-east-1.amazonaws.com
method: POST
path: /Prod
scheme: https
accept: application/json, text/javascript, */*; q=0.01
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,hi;q=0.8
access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: https://apiid.execute-api.us-east-1.amazonaws.com/Prod
content-length: 117
content-type: application/json; charset=UTF-8
origin: http://example.com
referer: http://example.com/
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/79.0.3945.130 Safari/537.36
Lambda function code:
var AWS = require('aws-sdk');
var ses = new AWS.SES();
var RECEIVER = 'example#gmail.com';
var SENDER = 'example#gmail.com';
var response = {
"isBase64Encoded": false,
"headers": { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*'},
"statusCode": 200,
"body": "{\"result\": \"Success.\"}"
};
exports.handler = function (event, context) {
console.log('Received event:', event);
sendEmail(event, function (err, data) {
context.done(err, null);
});
};
function sendEmail (event, done) {
var params = {
Destination: {
ToAddresses: [
RECEIVER
]
},
Message: {
Body: {
Text: {
Data: 'name: ' + event.name + '\nphone: ' + event.phone + '\nemail: ' + event.email + '\ndesc: ' + event.desc,
Charset: 'UTF-8'
}
},
Subject: {
Data: 'Website Referral Form: ' + event.name,
Charset: 'UTF-8'
}
},
Source: SENDER
};
ses.sendEmail(params, done);
}
No 'Access-Control-Allow-Origin' header is present on the requested resource.
This is saying that the resource you requested, your Lambda via API Gateway, is not returning an Access-Control-Allow-Origin header in its response; the browser is expecting the CORS headers in the response from the API (possibly because of an OPTIONS request), but the response doesn’t have them.
You’ve not said so specifically but I’m assuming you’re using a Lambda proxy integration on your API gateway. To solve your issue, add a Access-Control-Allow-Origin: * header to the response your Lambda returns. You’ve not specified the language your Lambda is written in, or provided your Lambda code, but if it was in NodeJS, a snippet of what you‘d return might look something like:
const result = {
statusCode: 200,
headers: {
'Access-Control-Allow-Origin': '*',
// other required headers
},
body: object_you_are_returning
};
return result;
Very surprisingly, the reason seems to be “the client-side shouldn't have 'Access-Control-Allow-Origin': '*'. That should only be in the Lambda code, apparently, and adding it to the jQuery code will cause the preflight to fail for some reason.”
https://github.com/serverless/serverless/issues/4037#issuecomment-320434887
Supplement information following the comment:
I also tried to use ajax hosted in S3 to call my Lambda function through API Gateway. I have tried many suggestions especially this solution (http://stackoverflow.com/a/52683640/13530447), but none of them works for me. In the developer-mode of Chrome, I kept seeing the error "Access to XMLHttpRequest at '[my API]' from origin '[my S3 website]' has been blocked by CORS policy: Request header field access-control-allow-origin is not allowed by Access-Control-Allow-Headers in preflight response." I solved this by removing 'Access-Control-Allow-Origin': '*' in ajax. Still take the solution (http://stackoverflow.com/a/52683640/13530447) as an example, it will work by changing
$.ajax(
{
url: 'https://npvkf9jnqb.execute-api.us-east-1.amazonaws.com/v1',
headers: {'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*'
},
crossDomain: true,
type:'GET',
dataType: 'text',
success: function(data)
{
window.alert(data);
}
});
into
$.ajax(
{
url: 'https://npvkf9jnqb.execute-api.us-east-1.amazonaws.com/v1',
headers: {'Content-Type': 'application/json'},
crossDomain: true,
type:'GET',
dataType: 'text',
success: function(data)
{
window.alert(data);
}
});

Call to AWSCognitoIdentityService.GetId for Cognito User Pools returns "Token is not from a supported provider of this identity pool."

I am using the AWS sdk for javascript and I am trying to use the new Cognito User pool service. I am getting an error from the underlying http request, accessing the Cognito API function AWSCognitoIdentityService.GetId:
POST / HTTP/1.1
Host: cognito-identity.us-east-1.amazonaws.com
Connection: keep-alive
Content-Length: 985
Cache-Control: max-age=0
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Type: application/x-amz-json-1.1
X-Amz-Content-Sha256: 9fba852db0a50678957c5be2a317ebce5edbb4580ad7cb1d7b524e2ff5bf95f7
X-Amz-Target: AWSCognitoIdentityService.GetId
X-Amz-User-Agent: aws-sdk-js/2.3.17
Accept: */*
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Request payload:
{"IdentityPoolId":"us-east-1:f9a5b209-8ed6-405d-987c-eb2954d30d1c","Logins":{"cognito-idp.us-east-1.amazonaws.com/us-east-1_9ymEVPkkL":"eyJraWQiOiJQUFhBemRsVDg1K29kNzNvTFU4cnFzVUZORVJvVkh2aVJERGV4bzdISmJzPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiI0OTNlYjk5MS1iMTgyLTQxYzAtYmZhNC00N2M5YzViMzM1OTMiLCJhdWQiOiI3N3U3MnRidjN2M2M2MG1pZXFlNGhhbW8yOSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJ0b2tlbl91c2UiOiJpZCIsImF1dGhfdGltZSI6MTQ2ODk4OTY4MywiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tXC91cy1lYXN0LTFfOXltRVZQa2tMIiwibmFtZSI6Ik5uZW5uYSBVZGVnYnVuYW0iLCJleHAiOjE0Njg5OTMyODMsImlhdCI6MTQ2ODk4OTY4MywiZW1haWwiOiJubmVubmFAZGFzaHBlZWsuY29tIn0.gItOyeKF3pu24aWtaUwPMQtcOAJu9TWqmYeT3N74zijI9QgfxL93fagZvVgsQj-rqtRSddVV05ZHJBXXZiUZdb3PnUDp48R_1Kiv1RhIvMqOO43RNyS9B7G4uD0cdM8S7OCaoJMXbDPwVH5jy_j9_anm7HgbRGi3JYLS10bIvvuqznxp75V6bxsTGhVGT8EHTui-l0yqLhLbPDM05JV0sOXANFS-BO4sYjgJ-VU8GrP6D49wbses524bMIDAIRN78me5WAFC6OzOqZQ9e_JNVbgs8pHaaDqpqTZq6RUGGUS0QykhDPoJImbS_tt5rGNrVFrDpKXcwJAD1hI5x6lrNA"}}
Response:
HTTP/1.1 400 Bad Request
x-amzn-RequestId: 8e6f7124-4e35-11e6-a6a6-d56ee4384e6b
Access-Control-Allow-Origin: *
x-amzn-ErrorType: NotAuthorizedException:
Access-Control-Expose-Headers: x-amzn-RequestId,x-amzn-ErrorType,x-amzn-ErrorMessage,Date
**x-amzn-ErrorMessage: Token is not from a supported provider of this identity pool.**
Content-Type: application/x-amz-json-1.1
Content-Length: 109
Date: Wed, 20 Jul 2016 04:51:01 GMT
Connection: close
This "Token is not from a supported provider of this identity pool" makes no sense. This token is what came from the user session cached during authentication. And the provided loginID is based on the format for the Cognito user pool.
Here is some of the sample javascript code:
this.loginId = 'cognito-idp.' + this.region + '.amazonaws.com/' + this.userPoolId;
this.poolData = {
UserPoolId : this.userPoolId,
ClientId : this.clientId
};
this.userPool = new AWSCognito.CognitoIdentityServiceProvider.CognitoUserPool(this.poolData);
cognitoUser.getSession(function(err, session) {
if (err) {
console.log(err);
console.log("user session expired. needs to log in");
this.navigateToLogin();
return;
}
var token = session.getIdToken().getJwtToken();
AWS.config.credentials.params.Logins[this.loginId] = token;
AWS.config.credentials.refresh(function(err){
if (err) {
alert(err);
}else{
onLoggedIn();
}
});
console.log('session validity: ' + session.isValid());
}.bind(this));
What is baffling me is that it used to work! And sometimes after many days of logging in and out I am able to get it to work again. But now it has all together stopped working. I wonder if this is a bug since this service is still in beta, or if there is something I'm doing wrong.
That exception is thrown from Cognito Federated Identities, not User Pools, so it wouldn't be because of service instability. It means that the logins key you gave doesn't match with what is linked to the pool and was configured from the console.
I'd double check that you have it configured on the console correctly, and if so, add some logging to see what is being sent as the key in the logins set when it does not work vs when it does.

cookies not being sent over the server

I have a backbone app (residing on mywebsite.proj.io) that takes code sends it to the django server (authorization.proj.io) that exchanges the code for an access token (simple oauth exchange). I am using Chrome/49.0.2623.87.
The authorization.proj.io sends a cookie back to the client (mywebsite.proj.io) during the auth stage, but this cookie never gets sent back again on future requests. I do not think it is a cross domain cookie issue or a browser unable to set a cookie on a 302 redirect.
I would like to know why the cookie is not be sent to the server on subsequent requests.
Here are some details:
Step 1: Request Header.. Authentication Phase Request: Sending the Oauth 'code' from mywebsite.proj.io to the authorization.proj.io to get the access token. This request is through ajax. The cookie you see here may be from a previous request, but do not care at this point really
GET /fbauth/?code=fb_code_long_string&state=%7B%22client_id%22%3A34343642979%2C%22network%22%3A%22facebook%22%2
Host: authorization.proj.io
Referer: http://mywebsite.proj.io/contribute/?code=fb_code_long_string&state=%7B%22client_id%22%3A34343642979%2C%22network%22%3
Cookie: csrftoken=1MTginTGXLHAku5LMHAMLLTrQEX2M4jj; sessionid=igc8a7vidgbi8rzxgm7whgb5rh8uqxa9`
Step 2: Response Header.. Authentication Phase Response [authorization.proj.io responds with 302 and gets redirected to mywebsite.proj.io and sets cookie]
HTTP/1.0 302 FOUND
Server: WSGIServer/0.1 Python/2.7.10
Vary: Cookie
X-Frame-Options: SAMEORIGIN
Location: http://mywebsite.proj.io/contribute/#access_token=CAAE
Set-Cookie: csrftoken=g0BEHLD0HAH4vBQLQFpKOEn2andrYMhG; expires=Tue, 14-Mar-2017 22:00:16 GMT; Max-Age=31449600; Path=/
Set-Cookie: sessionid=igc8a7vidgbi8rzxgm7whgb5rh8uqxa9; expires=Tue, 29-Mar-2016 22:00:16 GMT; httponly; Max-Age=1209600; Path=/
Step 3: Later, js from mywebsite.proj.io sends a requests to authorization.proj.io.. No cookie is sent
GET /posts/gcc-speaker-training-on-april-25 HTTP/1.1
Host: authorization.proj.io
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://mywebsite.proj.io
Authorization: Basic facebook:CAAEdTwh7fCMBAMEr6wC3ajZANVnZBMPenjseiNShjcXOJJ0PbiJ0GFXI7lSjzkP
DNT: 1
Referer: http://mywebsite.proj.io/contribute/
There were a few things I had to do to get this working.
It turns out that I was doing cross domain requests, and here is how I solved it:
1 : Ensure the server serving your pages has the Access-Control-Allow-Origin set.. I was using the http-server and did the following:
`http-server . --cors`
2 : I did the following for the ajax call
$.ajax('http://authorization.proj.io', {
type: "GET",
contentType: "application/json; charset=utf-8",
success: function(data, status, xhr) {
// do something;
},
error: function(jqxhr, textStatus, errorThrown) {
console.log("cannot get orgs");
},
xhrFields: {
withCredentials: true
},
crossDomain: true
});
Note the xhrFields and crossDomain.
3: I did the following in django settings.py:
CORS_ORIGIN_ALLOW_ALL = False
CORS_ALLOW_CREDENTIALS = True
CORS_ORIGIN_WHITELIST = (
'mywebsite.ngrok.io',
'authorization.proj.io'
)
SESSION_COOKIE_DOMAIN=".proj.com"
I think the last bit was important so that the browser can send the cookie.. So perhaps not cross domain, but cross sub-domain.