EVE Technology Lab

Imagine this situation:
You have multiple characters with director access to different corps on single account.
You generate api key for one of those corps and insert it into your application, let's say for using corp/IndustryJobs.
App accepts the key, gets corporationID from APIKeyInfo and starts fetching industry jobs for that corp.

Then you accidentally switch the corporation for that api key using https://support.eveonline.com/api/Key/Update/.
And now the application is screwed, because it has no way of knowing change like this happened. Unless it runs APIKeyInfo before every call of corp/IndustryJobs.

So, please, could you add corporationID attribute or node to every corp/... call. Also characterID for char/... calls, to be consistent.

That's all, folks.

"Char A" is director of "Corp A".
"Char B" is director of "Corp B".

Create api key "123456" for "Corp A".
Insert api key "123456" to application.
Application detects the key is for "Corp A" using APIKeyInfo.
Application keep fetching industry jobs fo "Corp A".
Change api key "123456" to "Corp B".
Application still assumes the api key "123456" is for "Corp A"

Application has no way to detect the api key was changed, unless running APIKeyInfo before every other call (with some exceptions, like CorporationSheet which has corporationID in it).

Yes it could be a problem but should only be a temporary one that your application should be able to recover from on it's own. First it's not a bad idea to be calling APIKeyInfo regularly because as you pointed out the owner can change it in many ways like changing expire date, changing access mask, all the way up to switching it between character, account, or corporation key types. You don't however need to call it every other call like you stated just at cachedUntil interval of APIKeyInfo which is 5 minute I believe. There are a couple ways to handle these kind of changes in an application.

One way is to deactivate the key on the first error from the API servers and require user to reactivate it manually at which time you can call APIKeyInfo to fine out what changes need to be done to use the new key or ask the user to make farther changes to the key so it can be used. I think of this as 'the punt it method'. You kick it away to the user to decide how to handle since they caused the issue to start with.

Another way is to take a more proactive approach where when you receive the first API error that suggest a change the application queries APIKeyInfo and reassign the key to it's new roles in the application. This requires the application to be more flexible in how it handles it's keys but is much more user friendly. This can mean you end up using more than one key for the same thing which depending on your application design is problematic if it is based on the idea there can only be a one to one relationship between application users, keys, and APIs. The application needs to look at the users to keys relationship as a many to many one that can have frequent changes instead.

Let me give an example of how I would like to see an application work. Say I decide to try a new application maybe web based or one I download and install. I setup my 'user account' with it which includes giving it one or more keys and vCodes. Now let's say the application needs a key which allows APIs A, B, C, and D but I have a couple different keys one of which allows A, B, D, and E APIs and another one that allows C and F. Now the application requires A, B, C, and D for it's main features X and Y but has an optional cool feature Z that needs E and F. The way most applications are currently designed I'd have to change one of my existing keys to have the correct APIs or make a new one with the APIs it needs. Let's just say for security I have made several different keys already for local applications I trust, web apps I trust plus several for others to use in corp and alliance applications as well so I've already used all ten that CCP allows at this time. Now I have to decide to change one of them and maybe allow something else or someone else access they didn't have before because of the new application I'm trying and not even sure I like yet. That's not really user friendly just developer friendly.

Now what if the application was designed to allow the user to have multiple keys which may or may not have overlapping APIs. In an application designed that way I could just add both of my existing keys and decided if I like it. Maybe I decide I like how it does features Y and Z better than an exist application I use and feature X I don't really care about or need. At that point I might decide to free up the key I use with the old application to use with the new one or since the new one is working fine with the two existing one and I've been want to try out another new application which needs APIs A, G, and H and I don't have a key with G and H active so I've been putting it off and now I can use the key the old application used since it wasn't one of the ones the new application I've decided to use needs.

Is the above example likely, probably not but developers that think outside the box and allow for things like this have a much better chance of being able to adapt to any other changes made by CCP to the APIs in the future.

Is designing an application to allow the above example's flexibility easy? No. Will it make it more future proof and user friendly? I think so but only with a lot of thought about how you handle adding keys and what to do when you have several keys with overlapping APIs. For me in Yapeal this has been fairly easy as everything in it has an 'owner' but that owner can be anything from a key, character, corporation to nothing at all for the eve, map, and server APIs. The only place there really is some minor issues is in account because the only usable 'owner' I've found was the key which means there is some duplication of data there.

Not a bad idea but I don't see how that changes anything really as the key itself is per corp and give you an error if you use it for a corp that it wasn't made for. This would only be needed if corp keys allowed access to corps from all the chars on an account which they don't so it's largely just a waste of time and bandwidth IMHO. I do always include characterID for the char APIs so I don't have to care if it's a account or character key I'm using for them. I'm more in the camp that account keys should be dropped then we wouldn't need to care with char APIs either but I'm sure its unlikely to happen because they can be more user friendly if not always as easy for the developers to work with.

Anyway that's my 0.02 ISKs on things.

Lumy and I have both been long time API developers so I knew why she was bringing it up so np.

You say you support multiple keys but the next question I always have is do you allow multiple 'accounts' per user? By that I mean do you allow them to have say more than one account type key which belong to different CCP sign-ins but are still considered a single 'user' in you application? For local single user applications like say EveMon that isn't really a problem since there isn't a 'user' per say but in any kind of web application it's something that comes up and so far all the ones I know about seem to want to limit one user per CCP sign-in which isn't very user friendly when you have multiple Eve accounts. You end up having to sign in and out just to use them which at least in my case means I don't use any of them currently because of the hassle that causes.

1. char/* calls aren't problem. I plan to force characterID param to every call, no matter if the key is account or character specific. If user changes the character for that key, at least I get an error response and have chance to disable key, instead of assigning data to wrong char.
2. ability of app to store/process multiple keys is irrelevant
3. running APIKeyInfo on cachedUntil (or before other calls as I mentioned) is solution, but:
- every developer must be aware of the problem and anticipate it
- every app must run APIKeyInfo on every key regularly and react accordingly
- out of curiosity, how does Yapeal handle this?
4. dunno how bout others, but without giving it second thought, my initial design was:
- ask for api key
- run APIKeyInfo once
- detect, what features I can offer for corp/char, what kind of data I can collect an process
- schedule appropriate calls
- in case user makes change to api key without letting app to know
-- if he restricts key from account type to char type, I'm good because server returns error for invalid characterID
-- if he changes key from one char to another char, I'm good because server returns error for invalid characterID
-- if he changes access mask , I'm good because server returns 221 error
-- if he changes key from one corp to another (without changing access mask), I'm screwed because I'm silently assigning e.g. industry jobs to wrong corp
5. since I'm now wiser, I'll
- run APIKeyInfo regularly
- in case user changes entity(char/corp) for that key, disable the key, or reschedule the calls
- then again: how about others? willl they do the same?

EDIT / PS:
and there are borderline cases like:
1. app callls APIKeyInfo
2. user changes corp for that api key
3. app calls IndustryJobs while APIKeyInfo is still cached
4. now you have batch bad data assigned to wrong corp

TL;DR in case of some corp/* calls, you have never 100% certainty what are you getting correct data for correct corp

Yeah, if we could do that, it would be great.

Lol, I actually haven't until now. It doesn't return error, the characterID gets ignored.

This should be reported as a bug I would think. Fixing this and having an optional CorporationID on the corp calls would certainly help those worried about potential data integrity issues related to users changing key settings.

Probably true, being specific about what you're asking for is usually a good idea to avoid confusion about the data returned. I can understand the "It's not really required for the call since we can just return the data relevant for the key" thought process from the CCP side though. The key in this case basically defines what you're asking for CharacterID wise, granted we're also trying to leverage the same parameter to be explicit and understand for sure what it is we're getting. Unintended usage due to little to no expectation of people changing the configuration of the key mid usage.

If you just change CAK type (from account to char) or character (character type or corporation type), it is still valid.

The whole point of this thread is that there is huge difference.
1. If you create new CAK, all is fine and dandy. If app tries to use old CAK, it gets error.
2. If you modify CAK, there is chance the app gets data for char (or corp) it didn't ask for. (Good luck cleaning up wallet journal after that)

Couple of ways to prevent (2) occurring
- don't allow to change CAK type/character once it's created
- automatically change keyID if CAK type/character is changed
- allow/force to send characterID/corporationID for char/* resp. corp/* calls and return error if it doesn't match key
- return characterID/corporationID in every char/* resp. corp/* call as attribute or element