By Mauro


2015-06-25 00:25:11 8 Comments

I originally wrote an REST API to work with a previously written mobile app. The mobile programmer requested from me to generate an auth_token on login that he will pass as a header on each request that needed authentication. This API runs at api.example.com.

Later on, I was commissioned to write an AngularJS app that communicates with this API, so I had to use Access-Control-Allow headers on the backend for OPTIONS requests to be CORS compatible CORS so my browser allows the connection (looks like iOS does not look for this headers). This app runs at one.example.com.

Now, I have to write a second AngularJS app that will run at two.example.com and there's a third being planned for the near future at three.example.com.

My problem is that my Access-Control-Allow-Origin header looks like this:

Access-Control-Allow-Origin: http://one.example.com:80

* is not allowed, nor I'm able to set this header to more than one origin. So as far as I can see I have two solutions:

  1. Implement token-based authentication in parallel to the current cookie-based one. I'm thinking on this. This will of course take some time I'm willing to save.

  2. Send the requester a header or param to the API endpoint identifying the app on the OPTIONS request and server-side, produce the CORS headers accordingly. I don't even know if it's possible and this looks nasty for even thinking it.

Any better ideas?

1 comments

@Yagiz 2015-06-25 00:37:18

If they have the same origin, example the same domain (example.com) or the same subdomain (1.ex.example.com and 2.ex.example.com) they can share the same cookie. Because cookie is based on the domain itself.

@Mauro 2015-06-25 00:44:15

The browser is automatically issuing the OPTIONS request and looking for an origin set in the Access-Control-Allow-Origin header. An origin is represented by schema + domain + port. If these three are not the exact ones that I'm using, the request fails. Am I doing something wrong then?

@Yagiz 2015-06-25 00:49:01

No @Mauro, OPTIONS request is used to identify the different HTTP methods that Client can use. Therefore, you should change the CORS settings from API side. You should write *.example.com as your cookie domain origin.

@Mauro 2015-06-25 01:05:38

that doesn't work: XMLHttpRequest cannot load api.example.com/auth/login. The 'Access-Control-Allow-Origin' header has a value 'http://*.example.com:9002' that is not equal to the supplied origin. Origin 'admin.example.com:9002' is therefore not allowed access.

@Mauro 2015-06-25 14:20:52

how is that relevant? That's just my local dev environment. I set the grunt server to that port so it doesn't conflict.

Related Questions

Sponsored Content

14 Answered Questions

12 Answered Questions

[SOLVED] No 'Access-Control-Allow-Origin' - Node / Apache Port Issue

5 Answered Questions

[SOLVED] CORS: credentials mode is 'include'

6 Answered Questions

[SOLVED] How to skip the OPTIONS preflight request?

  • 2014-04-09 16:20:55
  • Bram Vandewalle
  • 108628 View
  • 85 Score
  • 6 Answer
  • Tags:   angularjs post cors

14 Answered Questions

4 Answered Questions

[SOLVED] AngularJS + ASP.NET Web API Cross-Domain Issue

6 Answered Questions

[SOLVED] Set-Cookie in HTTP header is ignored with AngularJS

3 Answered Questions

4 Answered Questions

[SOLVED] Django CORS API from AngularJS

Sponsored Content