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.
12Next page
 

CAK potential problem

Author
Lumy
Sebiestor Tribe
Minmatar Republic
#1 - 2011-10-03 15:27:23 UTC
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.
Raiikon Xzinlai
Garoun Investment Bank
Gallente Federation
#2 - 2011-10-03 16:38:55 UTC
Lumy wrote:
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.


So you are saying you are using a key for all characters? Why not just create a corp key for each character with a corp to keep them separated?
Lumy
Sebiestor Tribe
Minmatar Republic
#3 - 2011-10-03 16:55:11 UTC
Raiikon Xzinlai wrote:

So you are saying you are using a key for all characters? Why not just create a corp key for each character with a corp to keep them separated?

"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).
Raiikon Xzinlai
Garoun Investment Bank
Gallente Federation
#4 - 2011-10-03 18:35:33 UTC  |  Edited by: Raiikon Xzinlai
Lumy wrote:
Raiikon Xzinlai wrote:

So you are saying you are using a key for all characters? Why not just create a corp key for each character with a corp to keep them separated?

"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).


I am curious how you are creating a general key that accesses the corp api without specifying the character associated with that corp. I have an account where all three characters can create corp keys (separate corps), but I cannot create an "All" key that has corp access. I have to pick a character, which makes the corp key unique. In order to "change the api key to Corp B", you should have to change the entire api key because it is for a different character.

Create api key "123456" for "Char A/Corp A"
Create api key "654321" for "Char B/Corp B"

If the application is reflecting api key "123456" and you want to change to "Corp B", you need to change it to api key "654321". They should be two separate api keys. Can you not enter multiple api keys into the application? I know many, if not most, apps for EVE handle multiple api keys.


---EDIT---

Okay, I think I see what you are doing, so let me know if this is correct. You are creating a single key, say "Char A/Corp A", and then after it is in the application, you are going back and updating that SAME api key to be "Char B/Corp B". Is that right? Because I can see your issue, but I believe that it might be taken care of after it parses the information again when the cache timer runs up. So it may not be apparent immediately because you are still pulling from cache.

BUT, my original point still stands. If the application supports multiple keys, just make a key for each character/corp instead of updating the same key to swap corps.
Dragonaire
Here there be Dragons
#5 - 2011-10-03 19:22:23 UTC
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.

Quote:
So, please, could you add corporationID attribute or node to every corp/... call. Also characterID for char/... calls, to be consistent.
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.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.

Raiikon Xzinlai
Garoun Investment Bank
Gallente Federation
#6 - 2011-10-03 19:47:44 UTC
Good info, Dragonaire. I guess my impression of Lumy's post was from a user view rather than developer, so I assumed it was regarding the use of an existing app. And from a developer standpoint, I code to support multiple keys so I have not run into this issue yet.
Dragonaire
Here there be Dragons
#7 - 2011-10-03 20:52:09 UTC
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.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.

Raiikon Xzinlai
Garoun Investment Bank
Gallente Federation
#8 - 2011-10-03 21:11:25 UTC
Dragonaire wrote:
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.


Yes, think of EveMon. A local desktop application handling data from multiple accounts. But I can understand the web applications restricting to one user/key. I will have to consider that if I get around to developing a web app.

And I have been around for a while but only recently decided to pay attention to the forums, so I am sure I will become familiar with people around here.
Lumy
Sebiestor Tribe
Minmatar Republic
#9 - 2011-10-04 08:15:58 UTC  |  Edited by: Lumy
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
Elegbara
White Wolf Enterprises
Harmonious Ascent
#10 - 2011-10-04 09:14:45 UTC
Can that be fixed by adding an optional corporationID parameter?

Open your eyes. And awaken.

Lumy
Sebiestor Tribe
Minmatar Republic
#11 - 2011-10-04 09:19:36 UTC
Elegbara wrote:
Can that be fixed by adding an optional corporationID parameter?

Yeah, if we could do that, it would be great.
Dragonaire
Here there be Dragons
#12 - 2011-10-04 16:01:01 UTC
Yapeal calls APIKeyInfo just like every other API based on it's cachedUntil DT. Remember something else is that CCP enforces a 24 hour cool off when switching corps where you can't have roles so the only real area to be handled is key owner switching key from one char to another. I would say there might be a brief period of time in Yapeal when API data could be stored for a wrong corp until APIKeyInfo is called again to refresh tables but its not something I've really looked at in depth yet. Now that it's come up I'll look into it some more to see if there's anything I need or can change to prevent issues.

Quote:
if he changes key from one char to another char, I'm good because server returns error for invalid characterID

I can see this being an issue with character keys as well since characterID is optional and the default by the API servers is to ignore any parameters they don't need to determine which data to return. Have you tested to make sure it actually returns an error if they don't match? I think I did but I was very busy at the time and I'm not sure.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.

Lumy
Sebiestor Tribe
Minmatar Republic
#13 - 2011-10-04 16:12:51 UTC
Dragonaire wrote:
Quote:
if he changes key from one char to another char, I'm good because server returns error for invalid characterID

I can see this being an issue with character keys as well since characterID is optional and the default by the API servers is to ignore any parameters they don't need to determine which data to return. Have you tested to make sure it actually returns an error if they don't match? I think I did but I was very busy at the time and I'm not sure.

Lol, I actually haven't until now. Oops It doesn't return error, the characterID gets ignored. Ugh
Dragonaire
Here there be Dragons
#14 - 2011-10-04 16:57:12 UTC
I was afraid of that.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.

Zaepho
GoonWaffe
Goonswarm Federation
#15 - 2011-10-04 17:27:29 UTC
Lumy wrote:
Dragonaire wrote:
Quote:
if he changes key from one char to another char, I'm good because server returns error for invalid characterID

I can see this being an issue with character keys as well since characterID is optional and the default by the API servers is to ignore any parameters they don't need to determine which data to return. Have you tested to make sure it actually returns an error if they don't match? I think I did but I was very busy at the time and I'm not sure.

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


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.
Dragonaire
Here there be Dragons
#16 - 2011-10-04 18:01:44 UTC
Actually making the characterID and corporationID required not optional and checked by CCP would be the way to fix things. They should always have the most current info and be able to detect conflicts.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.

Zaepho
GoonWaffe
Goonswarm Federation
#17 - 2011-10-04 21:11:55 UTC
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.
Kossaw
Body Count Inc.
Pandemic Legion
#18 - 2011-10-05 03:49:12 UTC
Lumy wrote:
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.



Well, technically Yes, but the situation is no different from you generating a new CAK - The old CAK is now invalid. I don't really see how adding more info to the returns of other API calls will resolve this - you are now using an invalid CAK, the API calls will fail, and the user needs to correct it.

WTB : An image in my signature

Lumy
Sebiestor Tribe
Minmatar Republic
#19 - 2011-10-05 06:06:01 UTC  |  Edited by: Lumy
Kossaw wrote:

Well, technically Yes, but the situation is no different from you generating a new CAK - The old CAK is now invalid. I don't really see how adding more info to the returns of other API calls will resolve this - you are now using an invalid CAK, the API calls will fail, and the user needs to correct it.

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
Kossaw
Body Count Inc.
Pandemic Legion
#20 - 2011-10-05 12:46:00 UTC  |  Edited by: Kossaw
Lumy wrote:

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

Gotcha. My Bad. Yeah, thats a nasty bug.

WTB : An image in my signature

12Next page