These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Problem trying to make SSO work

First post
Author
Previous Topic Next Topic
Emilie Sunstrider
Sunstrider Family
#1 - 2015-02-09 22:18:10 UTC
Hey there,

I'm trying to make SSO work, without a server side connection, only with JS (Angular). I can get the code in the https://login.eveonline.com/oauth/authorize/?response_type=code&redirect_uri=http://localhost&client_id=[myId]&scope=& (easy part) but when I try to post the code to using the $http method from Angular I get an OPTION request that fails:

OPTIONS /oauth/token HTTP/1.1
Host: login.eveonline.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36
Access-Control-Request-Headers: accept, authorization, content-type
Accept: */*
DNT: 1
Referer: http://localhost/?code=PWUWMBM1kuHRnYkOKIs4zwahYqTEL0WEv70beidQ54dsIvGJEtqtEFA3691fZqZq0
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,pt-BR;q=0.6,pt;q=0.4


this is my simple $http function:


$http({
                url : 'https://login.eveonline.com/oauth/token',
                method : 'POST',
                headers : {
                    'Authorization' : 'Basic Nz[suppressed]'
                },
                data : {
                    'grant_type' : 'authorization_code',
                    'code': userCode
                }
            });


this is the log from Chrome

XMLHttpRequest cannot load https://login.eveonline.com/oauth/token. The request was redirected to 'https://login.eveonline.com/Error/PageNotFound?aspxerrorpath=/oauth/token', which is disallowed for cross-origin requests that require prefligh


and this is the response headers from the OPTION request:

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /Error/PageNotFound?aspxerrorpath=/oauth/token
X-Powered-By: ASP.NET
Date: Mon, 09 Feb 2015 22:11:24 GMT
Content-Length: 163


what am I doing wrong? how can I avoid this preflight request?
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#2 - 2015-02-10 00:35:33 UTC
I'm not /sure/ but it might be the DNT header that's screwing with it. If it's not an allowed header, that might be messing with it.

The other thing to try is making sure that your Authorization header is correct.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter
Emilie Sunstrider
Sunstrider Family
#3 - 2015-02-10 01:08:40 UTC
I tried removing the DNT feature from the Chrome and it didn't work. Also, I made a manual POST using the DHC Chrome extension and it worked just fine. Looks like the Authorization header is the responsible for triggering the preflight.
Pete Butcher
The Scope
Gallente Federation
#4 - 2015-02-10 06:53:23 UTC
Is the data you're posting valid? Is the base64 valid? Is the content type application/x-www-form-urlencoded?

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool
Emilie Sunstrider
Sunstrider Family
#5 - 2015-02-10 22:04:46 UTC
Pete Butcher wrote:
Is the data you're posting valid? Is the base64 valid? Is the content type application/x-www-form-urlencoded?


It does. I tried the same request using a Chrome addon and it worked fine. Also, I double checked the Base64 encoded ids and it is correct. Here is the one-line-code from Angular:

 $http.post('https://login.eveonline.com/oauth/token', {'grant_type' : 'authorization_code', 'code': $location.search().code }, { headers : { 'Authorization' : 'Basic NzVhZTdhZjMxOWYxNDUwYzllMDdlNWZmODNl[truncate]', 'Content-Type' : 'application/x-www-form-urlencoded' }});
Pete Butcher
The Scope
Gallente Federation
#6 - 2015-02-11 07:26:54 UTC
Emilie Sunstrider wrote:
Pete Butcher wrote:
Is the data you're posting valid? Is the base64 valid? Is the content type application/x-www-form-urlencoded?


It does. I tried the same request using a Chrome addon and it worked fine. Also, I double checked the Base64 encoded ids and it is correct. Here is the one-line-code from Angular:

 $http.post('https://login.eveonline.com/oauth/token', {'grant_type' : 'authorization_code', 'code': $location.search().code }, { headers : { 'Authorization' : 'Basic NzVhZTdhZjMxOWYxNDUwYzllMDdlNWZmODNl[truncate]', 'Content-Type' : 'application/x-www-form-urlencoded' }});


Can you check the raw request it makes and verify it's OK? Maybe it screws something up.

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool
Chingy Chonga
Royal Amarr Institute
Amarr Empire
#7 - 2015-02-11 15:43:12 UTC  |  Edited by: Chingy Chonga
Try removing the ' around the Authorization for the header so it is just { Authorization : 'key' }?
Ortho Loess
Escalated.
OnlyFleets.
#8 - 2015-02-11 21:57:53 UTC
I've been working on a similar project this week: Took Steve's advice about using implicit flow for oauth, instead of the standard one. As far as I know, there's no way to keep your client secret secure in a javascript app.

Documentation says you have to use Code, but it actually works fine with implicit. (No refresh token though Sad)

My code is up on github, the SSO is working fine.

Unfortunately it doesn't help with your specific issue, as the step you are stuck on isn't used at all in an implicit flow.

According to the info I read on preflighting etc, any custom header at all triggers a requirement to preflight the request. All the ones I've done have worked fine though, being handled transparently by the browser.

The error you get back seems odd, since it appears to be trying to redirect to a page not found, rather than anything about auth failures.


That said: one possibility has just occured to me. The token endpoint may be configured to reject ANY request that doesn't have the correct content-type header set. I noticed when working with CREST that the content type header I specified was only set on the main request, not the preflight.

If that's the case, I'd probably call it a badly configured CORS implementation on the server. (or maybe even that endpoint isn't even set up for CORS, as it shouldn't really be being used with a browser based app.)

Unless you need the refresh token, I'd use implicit flow. Even if you do need the refresh token, be aware that anyone using the app can get your SSO secret.
Emilie Sunstrider
Sunstrider Family
#9 - 2015-02-11 23:07:27 UTC  |  Edited by: Emilie Sunstrider
Ortho Loess wrote:
I've been working on a similar project this week: Took Steve's advice about using implicit flow for oauth, instead of the standard one. As far as I know, there's no way to keep your client secret secure in a javascript app.

Documentation says you have to use Code, but it actually works fine with implicit. (No refresh token though Sad)

My code is up on github, the SSO is working fine.

Unfortunately it doesn't help with your specific issue, as the step you are stuck on isn't used at all in an implicit flow.

According to the info I read on preflighting etc, any custom header at all triggers a requirement to preflight the request. All the ones I've done have worked fine though, being handled transparently by the browser.

The error you get back seems odd, since it appears to be trying to redirect to a page not found, rather than anything about auth failures.


That said: one possibility has just occured to me. The token endpoint may be configured to reject ANY request that doesn't have the correct content-type header set. I noticed when working with CREST that the content type header I specified was only set on the main request, not the preflight.

If that's the case, I'd probably call it a badly configured CORS implementation on the server. (or maybe even that endpoint isn't even set up for CORS, as it shouldn't really be being used with a browser based app.)

Unless you need the refresh token, I'd use implicit flow. Even if you do need the refresh token, be aware that anyone using the app can get your SSO secret.


I'll try the implicit way like you did in your market browser.

but...
CCP needs to have a look on the IIS Server where the CREST is hosted. Reading the CORS W3C Recommendation, looks like that any request with additional fields (Authorization being one of them) needs a preflight using the OPTION request. Soooo, no response to an OPTION request, no fun allowed.

W3C wrote:
A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.

http://www.w3.org/TR/cors/#simple-method
Michael Bone
Viper-Squad
Pandemic Horde
#10 - 2015-02-13 04:46:24 UTC  |  Edited by: Michael Bone
I got SSO working in powershell, it may be worth just taking a look if you are still having troubles.

https://forums.eveonline.com/default.aspx?g=posts&m=5481857#post5481857