SSO Authentication 404s if you have every permission

[Ashterothi]

The URL used in the SSO is a 404 if you use every permission available. This is likely due to URL character limit. Please add either clustered permissions, or update the scope selector to determine if your chosen scopes will fail.

[SnipersCode]

Note that the maximum query string for IIS (which I assume the webpage is using because it is a IIS 404 error page) is 2048 characters. Minimum query string length for the endpoint not including the client id and redirect uri is 2047 characters when requesting all scopes.

I recommend at least having an "all" scope

[smclenithan]

It is also worth noting that the ESI scope names are on average significantly longer than the old scopes. While an all scope would be useful in certain situations we still need this to be fixed as a subset of all is still likely to exceed that limit without too much effort.

Currently if you are already logged in to login.eveonline.com then this issue does not occur as the IIS login server does not receive the redirect request.

https://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits

If we could get the maxQueryString and maxUrl parameters changed to something that can accommodate all current and future scopes that would be fantastic.

[snitchashor]

Would it be possible to use POST instead of a query string? Or just have integer IDs for all the scopes?

[antihax]

While it is possible per the RFC, the library I am using for OAuth2 does not support. If POST is implemented, it would be nice to have both GET/POST supported since this is a rare case that someone would need every scope.

[SnipersCode]

Corporate apps are the ones most likely and quite frequently going to need all scopes in order to grab all available information about the character and implement QoL services for members.

It should be noted that the OAuth2 Specification states that scopes needs to be a parameter in a GET request. https://tools.ietf.org/html/rfc6749#section-4.1.1

IMO, the best solutions in this case are either

1. Implement group scopes (all, all_read_only, assets, calendar, etc)
2. Change the maximum query string and url length
3. Shorten scope names

Remember that numbers 2 and 3 can cause regressions as more scopes are added.

[deadlybulb]

I deal with this now by maintaining multiple access tokens. Not ideal, but it works well for offline apps. The multiple authorization requests would be a pain for online apps.

[regner]

Multiple access tokens and requesting access to things as required instead of all upfront is what I do as well.

The goal for the SSO had always been to add the ability to group scopes. Not only does that help solve this problem, but it also makes the end user experience a lot better. It cannot realistically be expected that users read through and understand all of the scopes when a large number are requested at once. Grouping them is required to help ensure users understand what they are granting applications access to.

[lelandstarr]

While the RFC does clearly state that scope needs to be a request parameter, there is no verbiage stating that it has to be a query parameter. Unless I am missing something, there is no reason that this couldn't also be accepted as a "application/x-www-form-urlencoded" form parameter written to the get request and be fully compliant. I admit for an actual application you shouldn't need every single scope, however some of us (most of us) are building apps for ourselves, or playing around, and having all scopes available, at least until we have a finished product is quite a bit more convenient.

[Robbilie]

this is still a SSO and not ESI issue…

[SnipersCode]

While I agree this is primarily an SSO issue, the current issue is that the scopes for esi are much longer than the ones for crest.

@lelandstarr : According to the wording of the RFC that I had linked to above,

The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI
using the "application/x-www-form-urlencoded" format...

(emphasis mine)
While some packages have support for using the scope as a form parameter, not all do (as stated by antihax). The fact that the RFC states that it should be a "query component" implies, at least to me, that it must be a query parameter in the URI.

[tyler-sommer]

I ran into this problem in the last few days, glad to see it's already known.

@SnipersCode @lelandstarr: the OAuth authorize endpoint itself does need to receive the values in the query string, but it seems (as of today) that its not this endpoint failing. It's when the user is redirected to the regular https://login.eveonline.com/Account/LogOn page to enter their EVE user/pass, the "RedirectUrl" parameter (containing the full original OAuth Path+query params url encoded) causes the site to throw the 404.

Since the the OAuth authorize endpoint is on the same domain (login.eveonline.com), it may be possible to simply put the RedirectURL in the browser's cookies. But still, this would require changes to the login.eveonline.com site, so that might be out of the question.

I'd love to see this issue fixed, but the mentioned workarounds seem reasonable enough. You can also get around the issue if you ensure your browser is logged into EVE before attempting to authenticate your application. Not the best, but works well enough for development and testing.

[OrangeDrangon]

It would be nice if it was fixed via grouping so that users could know what they are agreeing to better and this problem could be avoided.

[evanova]

Can we have a hope of a resolution soon?

Being in the Android world, I cannot fiddle with the browser, I cannot possibly ask the user to log-in multiple times and maintain multiple tokens, and I am blocked in moving features from the XML API because the list of scopes I require is now getting too long.

Please?