1

I'm using Ember.js, Ember Simple Auth plugin and jQuery to send an Authorization header cross domain using ajax. When the Authorization header is set:

jqXHR.setRequestHeader('Authorization', 'Bearer ' + session.get('authToken'));

Then I get a pre-flight OPTIONS request to the REST URL which I then return back the following headers:

$headers->set('Access-Control-Allow-Origin', 'http://subdomain2.domain.com');
$headers->set('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS');
$headers->set('Access-Control-Allow-Headers', 'Content-Type, Authorization, Accept');
$headers->set('Access-Control-Max-Age', 10);
$headers->set('Content-Length', 0);

In Chrome Network monitor, this OPTIONS request returns successful. Then when the GET request comes after the pre-flight OPTIONS request, the GET request just hangs or at least says (pending) in network monitor:

enter image description here

If I refresh the page a couple of seconds later the page will show, but it just doesn't show immediately after the OPTIONS call.

When I play with the Access-Control-Max-Age header and increase the cache time, then I can refresh many times before it sends the OPTIONS call again which means the page will show just fine. It's only when the OPTIONS call comes with the GET immediately after does it hang.

When I load the url directly in the browser it displays the JSON data just fine. Even when I use the Chrome extension Postman and manually set the Authorization header the same as the jQuery request, it still loads the data just fine (although I don't think Postman simulates cross domain requests).

Any idea why the GET request remains pending and doesn't return any errors or headers?

Wasim
  • 4,953
  • 10
  • 52
  • 87

2 Answers2

2

Not really sure what the problem is here. Looks like you're running into sth. similar to this: cross-origin 'Authorization'-header with jquery.ajax()

Also, did you change anything in the Ember.SimpleAuth code? Because by default it shouldn't include the token in cross domain requests for security reasons...

You might also want to look at this known problem in jQuery: Sending credentials with cross-domain posts? that also relates to sending the Authorization header cross-domain.

I'll look into how Ember.SimpleAuth could maybe help in this scenario.

Community
  • 1
  • 1
marcoow
  • 4,062
  • 1
  • 14
  • 21
  • It's odd because if I refresh it seems to work, so I do return the correct headers after the `OPTIONS` request. I didn't change the `SimpleAuth` code - I did notice the line `if (!jqXHR.crossDomain && !Ember.isEmpty(session.get('authToken'))) {` but the `jqXHR` object doesn't contain the `crossDomain` property...I actually found the cross domain property is in the `options` object. Possibly a bug or a difference in systems? I've temporarily solved the situation by changing the `REST` server to the same domain. I don't think it's a `SimpleAuth` issue, maybe a bug...i'm not sure. – Wasim Nov 05 '13 at 08:36
  • I've also tried adding `jqXHR.withCredentials = true;` before it sends the `Authorization` header and this doesn't solve the problem. – Wasim Nov 05 '13 at 08:50
0

I did some investigation: in general Ember.SimpleAuth should work with CORS. I think what you're missing is the

Access-Control-Allow-Origin: http://subdomain2.domain.com

header in the response to the GET request. Also see the example in the Mozilla docs: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS. Every response must contain the Access-Control-Allow-Origin header.

HTH

marcoow
  • 4,062
  • 1
  • 14
  • 21
  • Thanks for checking. I definitely return this value as you can see from the question above `$headers->set('Access-Control-Allow-Origin', 'http://subdomain2.domain.com');` and it works when I refresh quickly so it's definitely not blocking the cross domain request. Maybe it's a bug in my system somewhere, i'll do some more poking around. – Wasim Nov 13 '13 at 14:06
  • hm, looked like you only had the headers in the response for the OPTIONS request not the GET. Also do you see anything in the log? – marcoow Nov 13 '13 at 17:06
  • Ah no had it for both GET and OPTIONS. If I didn't have it for GET none of the requests would work. Seems really odd. – Wasim Nov 14 '13 at 12:56