Cross Domain ajax OPTIONS error 403 (Django) - ajax

I'm developing some site aaa.com with django, which sends cross-domain ajax "GET" requests to receive json data from bbb.com which is also running on django and is using REST framework. At this point everything works pretty fine with adding crossDomain: true; withCredentials:true. And of course its configurated on server-side of aaa.com.
...-Allow-Credentials: true;
...-Allow-Origin: bbb.com
The main issue comes when aaa.com is trying to make PUT POST DELETE ajax requests.
According to CORS documentation:
[https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0], client side ajax request is correct, and
...-Allow-Headers, ...-Allow-Methods
is matched with
...-Request-Headers, ...-Request-Methods
so this request is not 'simple' and first of all browser sends preflight request from aaa.com to bbb.com to ask if some custom headers and methods are allowed.
Everything is OK But I'm still getting 403 Error. Here is the request/response:
General:
Request URL:http://bbb.com/api/someapipage/
Request Method:OPTIONS
Status Code:403 Forbidden
Remote Address:some ip:80
Response Headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:accept, content-type, x-csrftoken, x-requested-with
Access-Control-Allow-Methods:GET, POST, OPTIONS, HEAD, PUT, DELETE
Access-Control-Allow-Origin:http://aaa.com
Allow:GET, POST, HEAD, OPTIONS
Connection:Keep-Alive
Content-Language:en
Content-Type:application/json
Date:Mon, 04 Jul 2016 14:20:38 GMT
Keep-Alive:timeout=5, max=100
Server:gunicorn/19.6.0
Transfer-Encoding:chunked
Vary:Accept,Accept-Language,Cookie
X-Frame-Options:SAMEORIGIN
Request Headers:
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,ru;q=0.6
Access-Control-Request-Headers:accept, content-type, x-csrftoken
Access-Control-Request-Method:POST
Connection:keep-alive
Host:aaa.com
Origin:http://aaa.com
Referer:http://aaa.com/
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
After week of tries to fix this issue I realised that server wants to Vary: Cookie on pre-flighted request which is impossible because cross-domain pre-flight request cannot contain cookie in its header.
I started finding some solution to this issue and found:
https://code.djangoproject.com/ticket/13217
"Enabling django.middleware.locale.LocaleMiddleware causes that django adds a 'Vary: Cookie' header to every reponse."
So localMiddleware adds header Vary: Cookie even in pre-flight OPTIONS response
There are lots of reccomendations to use djang-cors-header to fix some of this problems. But using this package function are equal to my settings on server-side.
I have also found pretty package: django-dont-vary-on which if installed can set decorators to turn off Vary:cookie, but in my case i need to turn off Vary:cookie only in OPTIONS response.
Im bit new to django and actually cannot even imagine what to do in this situation. Every my step is just like walking on a mine field.
Is there any solution or some alternatives?

You have to CORS whitelist your client to access the server.
In case their is a Cross-domain request, the request becomes preflighted if you use methods other than GET, HEAD or POST.
Also, if POST is used to send request data with a Content-Type other
than application/x-www-form-urlencoded, multipart/form-data, or
text/plain, it becomes preflighted.
Its the server that allows the cross-domain client request to be processed or deny it (default).
So if you have access to the server-side application, you could do the following to get the response.
On server-side
Install django-cors-headers on your server side and white list your client domain or IP (it is also port specific)
pip install django-cors-headers
In settings.py, add it in your INSTALLED_APPS
INSTALLED_APPS = (
...
'corsheaders',
...
)
Add the corsheaders.middleware.CorsMiddleware in MIDDLEWARE_CLASSES
MIDDLEWARE_CLASSES = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'**corsheaders.middleware.CorsMiddleware**',
'django.middleware.common.CommonMiddleware',
....
)
and define a CORS whitelist
CORS_ORIGIN_WHITELIST = (
'aaa.com',
)
Now as you have added your client in the CORS whitelist, you will now be able to make a successful ajax request.

Related

should we close the connection of a pre-flight Cors request while sending response?

As I know that if cors request comes with some extra headers set, first server needs to process it.
With CORS, the server must send the Access-Control-Allow-Headers header to allow uncommon request headers from the client.
Access-Control-Allow-Headers ... - Comma-delimited list of the supported request headers.
e.g suppose my pre-flight request is
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
Then from server-side I will send response
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
My question is -
should I close the connection on server side while we send pre-flight response to client?
One more thing how can I cached pre-flight request for all other distinct subsequent requests?
Thanks
You could cache the OPTIONS request using the
Access-Control-Max-Age
header.
Attach it to the headers collection of the OPTIONS response.
But nevertheless an initial OPTIONS request by the user agent (browser) has to be made, you cannot avoid this.
But all further OPTIONS requests are cached and not issued to the server.
No need to close the connection.
Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: PUT
as explained here, search for
could have the following headers specified
to get to the designated text section.

Facebook Oauth CORS error

I am using oauth2 to handle a user login via facebook. The error occurs when I call the authorization server in the golang api.
Here is the network error.
Fetch API cannot load https://www.facebook.com/dialog/oauth?client_id=1543358959292867&redirect_u…=email+public_profile&state=mUi4IpdY8yF5TNVVptMNNSn8IbVSZxJXTSEFM8Zg8LM%3D. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
network info (chrome)
Request URL:https://www.facebook.com/dialog/oauth?client_id=1543358959292867&redirect_uri=http%3A%2F%2Flocalhost%3A7001%2FFBLogin%2FCallback&response_type=code&scope=email+public_profile&state=lkmenB4FjNOShUQzL0Gpymi1xsvauaL7TawmUjCyvI4%3D
Request Method:GET
Status Code:302
Remote Address:[2a03:2880:f003:c1f:face:b00c:0:25de]:443
request headers
:authority:www.facebook.com
:method:GET
:path:/dialog/oauth?client_id=1543358959292867&redirect_uri=http%3A%2F%2Flocalhost%3A7001%2FFBLogin%2FCallback&response_type=code&scope=email+public_profile&state=KPbwnGWQoI7PHvwhJ_JvZ7RowPthjqpaDTgKVI5NHrM%3D
:scheme:https
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8
origin:null
referer:http://localhost:3000/
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36
Javascript function that calls server api.
let loginUrl = "http://localhost:7001/FBLogin" //server url
let config = {
method: 'GET',
mode: 'cors',
}
fetch(loginUrl, config).then(response => {
...
}
Golang function that calls oauth authorization server (facebook).
func FBLogin(w http.ResponseWriter, r *http.Request) {
state, err := hashutil.GenerateRandomState()
logutil.Fatal(err)
url := config["fb"].AuthCodeURL(state)
logutil.OauthSessionLogger(state)
http.Redirect(w, r, url, 302)
}
I set the proper headers on the server side following this guide. Setting HTTP headers in Golang
I can't seem to find where the error comes from. (facebook API developer console, the callback headers in the server code, or the javascript initiating the call? I spent a lot of time changing the server headers but the error still persists as a CORS issue.
The origin in my request header is null, is that something to consider?
edit added no-cors mode result.
FBLogin 302 text/html SessionActions.js?524b:35 736 B 5 ms
oauth?client_id=154335&redirect_uri=http%3A%2F%2Flocalhost%3A7001%2FFBLogin%2FCallback&D
302 text/html
http://localhost:7001/FBLogin 611 B 57 ms
login.php?skip_api_login=1&api_key=154335 200
All three calls were successful, but was never redirected to the oauth page even when it said so. The response type was 'opaque' with a status 0.

AngularJS $http Authorize header not sent properly to RESTful service when developing locally but works in Cordova

I am developing an iOS application utilizing the Ionic framework with Cordova and have run into a bit of a snag in my dev cycle. While running on my local dev web server, any RESTful call happening from the $http service is failing with a 401 Not Authorized error even though I am passing the Authorization header. Interestingly enough, the call works fine once I build the app and deploy onto the iOS Emulator.
FWIW, the api calls are to an Atlassian Confluence api.
CORS doesn't seem to be the issue as that has been configured, tested and working on non-authenticated calls.
Here is the very basic call that is failing within the browser but working on the emulator when using the same headers:
$http.defaults.headers.common['Accept'] = 'application/json';
$http.defaults.headers.common.Authorization = 'Basic xxxxxxxxxxxxxx';
$http.get('https://www.example.com/rest/prototype/1/search/site?type=blogpost&spaceKey=TESTSPACE&os_authType=basic')
.success(function (data, status) {
this.serviceData = data;
})
.error(function (data, status) {
console.log(status, data.result);
});
I am sending two custom headers: Accept: application/json and Authorization: Basic *** If I run the application in Chrome with the above service configuration, I see the following Request Headers. There is an added Access-Control-Request-Headers that mentions the Accept and Authorization headers, but those headers are not there. I see the following Request Headers going across the wire:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Access-Control-Request-Headers:accept, authorization <!---- This is added but there is no Authorization Header
Access-Control-Request-Method:GET
Cache-Control:no-cache
Connection:keep-alive
Host:www.example.com
Origin:https://local.example-client.com
Pragma:no-cache
Referer:https://local.example-client.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
If I make the same call with the Authorization Header using the Advanced Rest Client Chrome extension, it works correctly.
Accept:application/json <!----------- This one is */* when called from $http
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Authorization:Basic *** REMOVED *** <!----------- This one is missing when called from $http
Cache-Control:no-cache
Connection:keep-alive
Cookie: *** REMOVED ***
Host:www.example.com
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
One thing to note is that if I remove the Authorization header line (below), then the Accept header now appears:
//$http.defaults.headers.common.Authorization = 'Basic ************************';
Can anyone provide me any insight on what I may be missing here?
It's probably a problem with your CORS configuration. Authenticated requests require very specific configuration to work properly with CORS.
Make sure you're
Returning the Access-Control-Allow-Headers header to allow those headers
Returning the exact origin in Access-Control-Allow-Origin (not "*")
Setting withCredentials to true on the XHR (in Angular this can be set in the defaults just like the headers)
(I'm not entirely sure if the "Authorization" header is considered a "credential" if you set it by hand so the last two may or may not be required.)
The reason it works under Cordova is because Cordova doesn't implement origin restrictions for XHRs (they would be a bit pointless since your app doesn't have anything "local" to communicate with)

Why is the browser not setting cookies after an AJAX request returns?

I am making an ajax request using $.ajax. The response has the Set-Cookie header set (I've verified this in the Chrome dev tools). However, the browser does not set the cookie after receiving the response! When I navigate to another page within my domain, the cookie is not sent. (Note: I'm not doing any cross-domain ajax requests; the request is in the same domain as the document.)
What am I missing?
EDIT: Here is the code for my ajax request:
$.post('/user/login', JSON.stringify(data));
Here is the request, as shown by the Chrome dev tools:
Request URL:https://192.168.1.154:3000/user/login
Request Method:POST
Status Code:200 OK
Request Headers:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:35
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
DNT:1
Host:192.168.1.154:3000
Origin:https://192.168.1.154:3000
Referer:https://192.168.1.154:3000/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Data:
{"UserId":"blah","Password":"blah"}:
Response:
Response Headers:
Content-Length:15
Content-Type:application/json; charset=UTF-8
Date:Sun, 16 Mar 2014 03:25:24 GMT
Set-Cookie:SessionId=MTM5NDk0MDMyNHxEdi1CQkFFQ180SUFBUkFCRUFBQVRfLUNBQUVHYzNSeWFXNW5EQXNBQ1ZObGMzTnBiMjVKWkFaemRISnBibWNNTGdBc1ZFcDNlU3RKVFdKSGIzQlNXRkkwVjJGNFJ6TlRVSHA0U0ZJd01XRktjMDF1Y1c1b2FGWXJORzV4V1QwPXwWf1tz-2Fy_Y4I6fypCzkMJyYxhgM3LjVHGAlKyrilRg==; HttpOnly
OK, so I finally figured out the problem. It turns out that setting the Path option is important when sending cookies in an AJAX request. If you set Path=/, e.g.:
Set-Cookie:SessionId=foo; Path=/; HttpOnly
...then the browser will set the cookie when you navigate to a different page. Without setting Path, the browser uses the "default" path. Apparently, the default path for a cookie set by an AJAX request is different from the default path used when you navigate to a page directly. I'm using Go/Martini, so on the server-side I do this:
session.Options(session.Options{HttpOnly: true, Path:"/"})
I'd guess that Python/Ruby/etc. have a similar mechanism for setting Path.
See also: cookies problem in PHP and AJAX
#atomkirk's answer didn't apply to me because
I don't use the fetch API
I was making cross-site requests (i.e. CORS)
NOTE: If your server is using Access-Control-Allow-Origins:* (aka "all origins"/"wildcard origins"), you may not be able to send credentials (see below).
As for the fetch API; CORS requests will need {credentials:'include'} for both sending & receiving cookies
For CORS requests, use the "include" value to allow sending
credentials to other domains:
fetch('https://example.com:1234/users', {
credentials: 'include'
})
... To opt into accepting cookies from the server, you must use the credentials option.
{credentials:'include'} just sets xhr.withCredentials=true
Check fetch code
if (request.credentials === 'include') {
xhr.withCredentials = true
}
So plain Javascript/XHR.withCredentials is the important part.
If you're using jQuery, you can set withCredentials (remember to use crossDomain: true) using $.ajaxSetup(...)
$.ajaxSetup({
crossDomain: true,
xhrFields: {
withCredentials: true
}
});
If you're using AngularJS, the $http service config arg accepts a withCredentials property:
$http({
withCredentials: true
});
If you're using Angular (Angular IO), the common.http.HttpRequest service options arg accepts a withCredentials property:
this.http.post<Hero>(this.heroesUrl, hero, {
withCredentials: true
});
As for the request, when xhr.withCredentials=true; the Cookie header is sent
Before I changed xhr.withCredentials=true
I could see Set-Cookie name & value in the response, but Chrome's "Application" tab in the Developer Tools showed me the name and an empty value
Subsequent requests did not send a Cookie request header.
After the change xhr.withCredentials=true
I could see the cookie's name and the cookie's value in the Chrome's "Application" tab (a value consistent with the Set-Cookie header).
Subsequent requests did send a Cookie request header with the same value, so my server treated me as "authenticated"
As for the response: the server may need certain Access-Control... headers
For example, I configured my server to return these headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:https://{your-origin}:{your-port}
EDIT: this approach won't work if you allow all origins/wildcard origins, as described here (thanks to #ChandanBhattad) :
The CORS request was attempted with the credentials flag set, but the server is configured using the wildcard ("*") as the value of Access-Control-Allow-Origin, which doesn't allow the use of credentials.
Until I made this server-side change to the response headers, Chrome logged errors in the console like
Failed to load https://{saml-domain}/saml-authn: Redirect from https://{saml-domain}/saml-redirect has been blocked by CORS policy:
The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. Origin https://{your-domain} is therefore not allowed access.
The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
After making this Access-* header change, Chrome did not log errors; the browser let me check the authenticated responses for all subsequent requests.
If you're using the new fetch API, you can try including credentials:
fetch('/users', {
credentials: 'same-origin'
})
That's what fixed it for me.
In particular, using the polyfill: https://github.com/github/fetch#sending-cookies
This may help somebody randomly falling across this question.
I found forcing a URL with https:// rather than http:// even though the server hasn't got a certificate and Chrome complains will fix this issue.
In my case, the cookie size exceeded 4096 bytes (Google Chrome). I had a dynamic cookie payload that would increase in size.
Browsers will ignore the set-cookie response header if the cookie exceeds the browsers limit, and it will not set the cookie.
See here for cookie size limits per browser.
I know this isn't the solution, but this was my issue, and I hope it helps someone :)

prototypeJS Ajax call vanishes

I've got a problem with an Ajax request in my web project. Most of the time it works just fine but sometimes there is simply no request from the client (it does not show in wireshark), FireBug just shows the request marked red.
Project looks like the following:
Java Backend with JSPs, Client is using the Firefox Browser
The request is done via prototypejs using the Ajax Updater function. I can debug the request preparation via firebug until the Ajax Update function fires the request but then no request is listed in my wireshark output (although all other request are listed just fine).
So I have a (sometimes) vanished Ajax request with no error and no clue where to look :( Any help would be much appreciated.
Request:
[...]/ajax/gruppe/loadTreeList.do?ajax=true&tstamp=645&context=GRUPPE&level=0&it‌​emid=0
RequestHeader:
Accept text/javascript, text/html, application/xml, text/xml, /
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Cookie JSESSIONID=326D8AEAAFD254760CEC8D050734807E
Host localhost:8080
Referer [...]/domain/druck/gruppe.do
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
X-Prototype-Version 1.7.1
X-Requested-With XMLHttpRequest
There is no response.

Resources