EveSSO url and standard limit to urls

Hi all.

I am just querying how we are getting round the recommended URL char limit when requesting tokens. Some browsers like chrome don’t seem to have a limit, but others do. IE 10 for example still suggests it uses the 2083 char limit. And it is still recommended that url’s do not exceed 2048 to be compatible with all browsers.

The issue of course is when i have a character in my corp who is obvious a character in his own right but is ASLO the ceo. Meaning i will be using his key/token to pull corp data. So, as 1 character can only have 1 token…that means for that character i need to requests all character scopes and all corp scopes. that adds up to about 3373 characters. This means the url i use to send my guy to the eve login server to get my token already have a url that is longer than the recommended limit ? Depending on the browser he uses it, will depend on whether this breaks…

The only thing i can think of is to use javascript to set the scopes as a header, but i don’t think ccp supports this. It is expecting a url with a redirect, scopes etc sent to it, and this URL will already be to long.

Any thoughts on this. ?

In the ESI panel and 3rd party “player talk”, there was mention to only request scopes as features are requested by the user… thus, the initial login is one… to do character stuff may be another, and finally corp is a 3rd.

In this way, the strings are smaller, and also the external client of your app is “fully aware” of what scopes are being requested for which feature in your app.

Although it may seem like a pain, it may be clearer to the end-user as well as offering a solution to your problem.


Knic o7

The issue is, i cant.

Like a lot of web services that rely on API data, a lot of this happens in the background. In the same way yapeal etc worked. AKA, every 5 mins my system looks for all characters who have not been processed last time, It then goes though ALL the things i need, assets, etc and pulls them and updates a database. ESI is designed to be stored, but ccps has not given any though as to how we store things. For example, there is no way to determine primary key from swagger schema. Like xml, esi is better, but its still a half arsed ccp botch it and leg it, but that’s another story.

The issue is, to run a service like yapeal, where i get refresh tokens then continually refresh data via cron jobs, i need all keys to have the required scopes already.

Also, as any web admins knows, the moment you force people to log in EVERY time they visiting your site…you can grantee they will never visit the site. This means we go to all the work, for a service no one will use because ccp have mad it so i have to make people log in every time ?>

That means ccp have created a server that is not worth implementing, because i know fora fact that if I make my corp log in to my site EVERY time they want to do anything…they just wont bother with it.

It isnt a pain…its a game breaker.

Also, the idea that we have to login with specific scopes on use, means that ESI is designed to be consumed, not stored. Yet it is cached, meaning they expect us to store data and obey cache timers ???

This kind of feeds into my other story… ccp has once again thrown this together without any real thought to the end user. They are expecting us to store data so as to mot spam them as we are expected to obey cache timers, we can’t do that without at the VERY least, storing the json and recording timers. But, due to how the Keys now work…we are being asked to make real time requests, requesting scopes as needed…and that means they want use to consume esi data, not store it… Either they are asking us to do both, which makes no sense, or more likely , they have given it any thought at all, and this is another half baked api from 1 man working part time on a service they have committed to but don’t really want to spend the time to develop properly

I either store data and obey cache timers OR i consume data and don’t store it at all …which is it ccp ?

I see the problem… Maybe go to CCP’s GitHub page and report this as an issue. See here:

ESI certainly isn’t getting any less scopes and it might be a good idea to have meta scopes - scopes that give broader access including one for all scopes.

Regarding the expire timers… you are not forced to cache data locally, but for the sake of your own application does it certainly help when you reduce the number of request to the ESI server to minimum, because they all cost you several milliseconds if not 100ms-200ms depending on ones Internet access speed. The expiration timers are then helpful in determining when you should make a new request and when you can use locally cached data. You can also ignore the expiration timers and cache data for much longer. So do region names not change, yet region data does expire every 24h and around downtime. So you really should not try to make a request each time you want to know a region’s id, but use cached data or better yet a local database, which contains most of the static data. Your users will be grateful, when pages pop up within less than a second and they don’t have to wait 5 seconds or more for every click they make.

i don’t think reporting it will do any good as they have build as system that in fact violates a an unofficial understanding that urls should not be more that 2048 long…

And that they have written is a drivel as all its says is obeying cache timers is not minatory but will make you site faster… Yes it will if i consume data on the fly and generate pages waiting for esi to return data …

Imagine the following …

I am an admin of a guild website offering services provided by esi. If offer all the services provide by esi, i dont know which ones you want to use. Do you want to look at your assets ?, your emails, your corp emails…you corp assets ???

Ok, no issue, what i will do is, each time you use a service you will have to LOG in again and create a brand now token for me with the correct scopes… So each time you want to look at your assets, you have to log in. If you want to now look at your emails… that’s right, log in again…now corp assets, log in again. Who the f%^& would use that as a service !!!

If i provides all the services that ESI offers, i cant know at any given time what you might want to do. So either i make you log in for EACH service, or i requests scopes for all the services I provide…that breaks the url standard limit !!!

So, in summary ccp is saying make a services that breaks on a lot of browsers or make one that no one wants to use, and those are the only 2 types of site you cane make with out pieces of junk api ? !!!


It’ll do more good than what you’re doing here right now. :rofl:

to me, you are just someone that doesn’t like change and cry about it right now.
Even if some of your arguments are rights doesn’t mean you have the right to throw stupidity like that

they have given it any thought at all, and this is another half baked api from 1 man working part time on a service they have committed to but don’t really want to spend the time to develop properly

Especially, when : they are not just 1, they are reactive, and you can ask for explanation / provide suggestions etc to almost everything they do, by using github issues and/or slack.
You don’t want to use it ? Fine, deal with it then.

Live (or leave) with it, anyway you won’t have the choice.
And fyi, there are things named “session” or “cookies” in the web, so you can always have a solution not to have your enduser log in with 2405134 useless scopes.

Have fun developping your tool :wink:

I remember hearing about this issue, iirc the workaround was like:

  1. Login via https://login.eveonline.com
  2. Click on the SSO button and it should work
  3. Loggoff via https://login.eveonline.com/Account/LogOff
  4. Repeat for other characters.

Ok, tell me then…mast Althalus ( don’t steal names from book, make your own) How would you develop this…

I need to offer services to my users. But if i forces them to log in over and over they wotn use it.

It must include all corps scopes like members tracking assets because the sites RUNS by syncing those in game features with permissions on forums and discord services. That means i need most of the scopes.

Enlighten me please ?

There is no need to be rude or offensive about people because you are holy than thou. Especially as you dont know the who thing.

Its not about me not liking change, its about that fact that i have a service running for almost 5 years… All forum and discord features are all determined by in game data, fro me to request the same data i have from XML, i have to break the entire site. So, because ESI isn’t an improvement, it is forcing me to ditch half the services my sites offers, or make it so no one will use the site anymore. Sorry if i seem bitter, but that’s a big deal.

Also, thanks for the helpful comment regarding my personal traits…It really help this . There is a saying Althalus Stenory, if you cant say anything nice, don’t say anything. OR roughly translated to. Can you please just … off. Thx.

The way I do it is to use the initial one-time code and use it as a session identifier. I simply store it in a cookie in the user’s browser and in my database.

Whenever a user visits a page with said cookie do I compare the cookie with what I have in my database and if it’s valid then I refresh the access without sending the user back to the SSO login. Logout is then implemented by clearing the cookie, which means having no cookie sends them back to the SSO login process.

thx for your input Blacksmoke16.

The issue i have isn’t getting all chars. The cancel on log int to get other chars is clunky and dumb but people can put up with that.

The issue is my site already offers a lot of services provided by api data. In order to provide the same services using ESI i have to create login URLs that are to long for most browers, OR i force my users to relog in depending on what services they want.

So for example. Take the CEO of my corp. He creates his token for his character by login in to eve and i get the access token back for all character scopes. Ok, that’s ok. But…now i cant use that token to get anything for the corp. SO, he has to logout of eve, aka, go to log in, cancel to log out, then log in again with the new scopes requests to use any corp things…

As i don’t know what services someone wants to use, i have to request the scopes for all the ones they might want OR force them to log in over and over depending on the service thy want. however if i do the later, the url to send the guy to the log in is over 2048 characters long, meaning on some browsers it will fail.

Unless i can think of something i cam going to have to ditch most of the services i provide, which then begs the question is it worth having the site at all

that would work for a limited number of services, but my site has been growing over the last 5 years.
It offers so many things now. multi-char asset searching, ingame email, char viewers, corp member management, permissions syncing with external serves like discord. Skill planners doctrine managers, doctrine managers building skill plans for pilots , indy tools the list goes on. I will have people logging in repeated all the time, and everyone will just stop using something i have spend 5 years building.

And all because CCP have replaces something bad that worked, with something better that doesn’t…
For all the new features ESI offers, none will do me any good if no one can be bothered to visit the site anymore cause they have to log in 3 times a session to use half the features.

Sorry if i seem like i am ranting but…i am really pissed that this has broken 5 years of my life that i cant not fix without breaking the site i created lol

You definitely should take this to CCP.

Ah right, the issue that workaround was for was when CCP was having the issue with their login server a while ago.

Couldn’t you just drop support for the older browsers with the limits. Like to best utilize this site use a modern browser like chrome or firefox.

this is the same conclusion that me and my CEO just came up with.

Basically, register with chrome or edge, or leave the corp, this feels really crappy as i know people who went to edge, all their plugins broke they rolled back to 11 and it has the limit. Effectively i am telling people they have to use chrome or pesh off.

That seems really shitty, but it is what it is. As chrome and edge and MAYBE safari are the only browsers that support urls longer than 2048 chars.

But the real reason CCP is to blame for this is simple.

esi-bookmarks.read_character_bookmarks.v1 that is one scope…it is 41 characters long. WHY, why does it need to be that long …

how about esi-char-bm-read. that would have done.
if ccp make scopes that were smaller. Also, have scopes access multiple end points. If i can ready your private char info, surely that same scope could be used for clone info and implants etc. role up the scopes/

@CCP really …

What is your use case for requesting all scopes?

Hi EveData.

The reason for all scopes is the current number of things my site does WITH xml and crest.
We are not talking about something new with esi, we are talking about converting something existing to use ESI because xml and crest is going away.

Currently my services stores keys and then constantly updates a database of data for use in services.
Data being pulled includes:

Corp: members security, titles, roles ,assets, member tracking, wallet journal, wallet entries, corp mail. ALL indy jobs doctrine managers these are just some of the corp features.
Char: char viewers, wallet viewers, push doctrines to eve, view doctrines, wallets, journals ,assets, emails , all indy jobs, skill planners again, this is not the complete list.
Other core service is the integration of permission with in-game roles and titles AKA if you are promoted to director in game within 5 mins you will be added to the correct forums permissions and discord channels and other services like pigin etc.

There are currently 178 scopes in game, for services which i use NOW. Looking at what my auth platform does, it uses 90% of all scopes…
Hence why i need them all. Because my platform uses them. You name it…it does it. 5 years in the building :confused:

So, i either drop services, force multiple logins per session or force all uses to use the browser of MY choice.
But black is right, it is the only real options. So, if you are in my corp, sorry, its chrome or there is the door.

There are 69 scopes. You could likely cull some of these below:


My second recommendation (graciously stolen from CCP Bartender) is to break the scopes into specific use cases, which helps you control access with more granularity.

For example:

  • A generic user: minimal scopes needed for application to function.
  • Director: additional scopes for director level information.
  • CEO: additional scopes for CEO level information.
  • Cap Pilot: scopes for pilots with capitals.
  • FC: scopes for FCs.

You end up with more tokens, but the group of scopes are smaller and allow tighter management on both the user and administration. You and the user can add or remove permissions much easier.

Most users should be very paranoid of applications asking for access that has no use for it. This helps prevent you from requesting things from users that you really do not need.

You can’t have more tokens. i need 1 token from each char in my corp. To run all char services i need all char scopes as i use every single one bar open a window. Some chars will need other scopes…and the ceo needs all the coprs ones aswell.

You have a character. If i want to pull any data about you, i need your scopes for that. But, i cant create a separate corp token for that person. I have to just add the scopes to HIS token. One Char. one token, multiple scopes. To change scopes requires a new token.
So, yes, i could just request the character info for anyone char, this would result in a url less than 2018. What however do i do with my CEO. He is a character to. I still want his char data. BUT, i also need his token to access corp asset etc. His URL is now broken, as it is to long.

In regard to your scopes. i use all bar one, the open ui_window, as its a future scope with no current use. And my platforms does a hole lot more than the above…

Journals ? contracts ? indy jobs ? structure managers, fuel monitors…all services currently running, that need data from someones key/. from scopes listed not above. Now in the real world we would have the Director of marketing, and the finance director. Maybe i could just requests specific scopes per director…but, this isn’t real life. And i don’t. I have 3 directors…and no division of responsibility per say. and the moment someone leaves and we haven’t replaced that director…ooops have the website stops worked… Hence why i have ONE corp token from the CEO only, as you cant not leave without making someone else CEO and i will know the moment you do.

CCP Bartender suggestions are work arounds for a broken system.

Basically CCP Bartender say’s Make your corp more granular in the way it runs, because we have made a heap of crap api and you need to completely change how your work and rewrite 5 years of code, because we are bad at our jobs…

Nice, thx ccp…

Anyway. The solutions has already been defined, even if it is not ideal. I am not willing to drop services, some of which have been running for year. So, i must for all users to use chrome to access the site. If for some reason you cant use chrome wont use chrome, you will have to leave corp. its ■■■■, but it is the only solutions that doesn’t force multiple logins per session OR requies me to drop some services.

I consider this now closed. Thx for those who have tried to help and offer solutions, all except Althalus Stenory, your a cuk.

An important point:
Don’t require the user to log into your service with a scoped login.

The only time you should be requiring scopes is on registration. Have them register with a scoped login, and store the refresh token. Then, after that, they log into your app with an unscoped login.

If they’re a director, have them register with the character scopes, then add another login for another refresh token, with the corp scopes.

Then, when you need to do stuff with a scope, pick the appropriate token from your database, and use it.

If you ever need a new scope, have them log in with it.

So you’d have your user table (keyed on characterownerhash), a token table (keyed on character id, and linked to the user table). and a scope table (linked to the token table. ideally one entry per scope)