Open jdhiro opened 10 years ago
Thanks for bringing this up, I didnt know you could skip the pre-flight options request w/ CORS. I will look into adding support for the Auth header over next few days.
Awesome, thanks for the quick response! Great module BTW -- much easier than trying to use an OAuth password grant for basic REST authentication over HTTPS.
Thanks for the feedback, glad its useful!
OAuth can be a pain for basic stuff which is why I originally wrote this library. I actually also have a laravel oauth2 server package https://github.com/tappleby/laravel-oauth2-server that I use on some bigger projects, never ended up writing the documentation for it though.
Hmm. I'd hoped that laravel-auth-token would use JWT. According to Auth0, any AJAX request invokes a CORS preflight, anyway: https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/ You might also like these guidelines: http://security.stackexchange.com/questions/51294/json-web-tokens-jwt-as-user-identification-and-authentication-tokens JWT is great, because it is an open standard, and comes with power, and tools, like: http://kjur.github.io/jsjws/index.html#demo
I think tappleby has a work in progress JWT branch. I've done a decent amount of CORS testing/work and it is not always fired, at least in Chrome. They do a pretty good job following the rules I linked to.
Jdhiro- I see feature/jwt thanks! If you can help explain where CORS fails, this would be helpful, for prevention. I expect that you can use a JWT token the same way as a laravel-auth token, so it should be no worse. I had seen an article, on embedding JWT in the URI, but could not find it again. You can always embed it in a ReST style mod-rewritten URI, or as a POST parameter. I expect that these would not require a pre-flight request. I looked in CORS In Action (Manning, the only CORS book I currently know of). It suggests removing the Content-Type header for JSON, so you can avoid preflight, after all. Perhaps this is what you meant. This clarification helps the rest (no pun) of us Here is a reminder to test or specifiy out, old, pre-CORS spec, IE9 Cross-Domain Requests.
Yeah I created the feature/jwt branch when that auth0 blog post was first posted. Not much progress was made with it, there was not many options for php JWT at the time. I will probably switch to using the firebase library mentioned here: http://jwt.io/
My goal is for the next version of this package (v0.4.0) is to use JWT by default.
In my quick tests using the Authorization
header instead of X-Auth-Token
+ no Content-Type
header skipped the preflight request from being sent.
The above tests were done in chrome, havent tested other browsers yet.
@bingalls the link that I referenced on MDN lays it out pretty clearly. I also wouldn't say that CORS "fails" anywhere. Pre-flights are normal/expected in many cases, you can just avoid them, by spec, by following a few rules.
The app I'm working on right now just happens to have extremely high performance requirements, so I'm looking to shave time anywhere possible. Extra OPTIONS request is a good place to save time.
@tappleby Firebase auth0 is big, but also look at https://github.com/tymondesigns/jwt-auth I'm hoping v0.5 or v0.6 will integrate with authorization, etc, as with https://github.com/intrip/laravel-authentication-acl
Currently laravel-auth-token uses the X-Auth-Token header. However, according to CORS, using a custom header forces a pre-flight OPTIONS request (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests).
This probably isn't an issue with native apps, but with single-page web apps a second OPTIONS call is always made that doesn't need to really be made. I'm using AngularJS.
However, standard headers, such as the 'Authorization' header do not cause a pre-flight request. Authorization can also be customized by setting a string before the token. For example, "Authorization: bearer [token]" is typical, but "Authorization: laravel [token]" could be used as well without creating a pre-flight request.