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.
Previous page12
 

CAK potential problem

Author
TorTorden
Tors shibari party
No Holes Barred
#21 - 2011-10-05 20:28:00 UTC
I can see this being a bonafide issue, but here's one thing I like of being a hobby dev working for free.
When a user is being an idiot I can call them on it.

Personally best solution for something like this is as suggested above to call apikeyinfo routinely.

Maybe we could leverage this to get more than ten keys pr account?
Kossaw
Body Count Inc.
#22 - 2011-10-05 21:10:33 UTC
I think the fastest easiest and best solution is for CCP to remove the ability to change the CAK Type or vCode after it has been created.

If we have to call AIPKeyInfo to verify keys, then you have to do this immediately before EVERY api call to make sure nothing changed in the last few milliseconds. Congratulations CCP, you just doubled the number of requests made to the API.

WTB : An image in my signature

Kossaw
Body Count Inc.
#23 - 2011-10-10 07:50:17 UTC
Apparently the Bug Hunting team is too busy to realise just how f**d up this bug is and that they have just doubled the required number of API calls.

=============================

// This is By Design. Also please note there is a special API call account/APIKeyInfo.xml.aspx which returns information about the API Key, including type, access mask and characters it is generated for.
// BH Eriweal

WTB : An image in my signature

Dragonaire
Here there be Dragons
#24 - 2011-10-10 09:54:00 UTC
Actually most of the time it won't be that bad as like in the past the API key info is cached for up to 5 minutes on their side so until APIKeyInfo changes everything should be correct and everything you get from the APIs should be for the old info. We are talking a unusual edge case here that is more likely to happen during development testing where people are more likely to do stupid stuff like re-tasking an existing key.

It would be nice if when changes are made to a key the API server won't allow any APIs to be downloaded until APIKeyInfo has been accessed again. If it would return an error code for the other APIs instead to let you know there had been a change it could even be handled automatically to force an update call on our end.

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

Matalok
Slackers and Nihilists
#25 - 2011-10-11 08:30:34 UTC
Dragonaire wrote:

It would be nice if when changes are made to a key the API server won't allow any APIs to be downloaded until APIKeyInfo has been accessed again. If it would return an error code for the other APIs instead to let you know there had been a change it could even be handled automatically to force an update call on our end.


Sounds like a caching and race condition nightmare. You can never be perfectly in sync with the API due to the way it works. The easiest thing you can do is if you hit a error 221 on a call that should be OK to run then you need to update the key details with APIKeyInfo.
Kossaw
Body Count Inc.
#26 - 2011-10-12 12:00:30 UTC
Have you considered that malicious users may exploit this bug to deliberately try to feed you false data ???

Seriously, the simple fix is to prevent users from changing either the Type, Corp or Character for an existing CAK. Ten minutes work on the support web page where CAKs are generated will fix this problem without need for complicated alterations to the API system.

WTB : An image in my signature

Tonto Auri
Vhero' Multipurpose Corp
#27 - 2011-10-14 04:42:40 UTC  |  Edited by: Tonto Auri
Kossaw wrote:
I think the fastest easiest and best solution is for CCP to remove the ability to change the CAK Type or vCode after it has been created.


Fk'n this.
There's absolutely no point at CCP's end to provoke API hammering with requests applications are not need for correct function.

Thinking about this, there's should be only ONE management button to the created key - INVALIDATE.
That's all.

Two most common elements in the universe are hydrogen and stupidity. -- Harlan Ellison

Dragonaire
Here there be Dragons
#28 - 2011-10-14 07:19:30 UTC
Last few comments are great and all but they forget one point you only get 10 key period so what happens when you use them up? If you can't change them you stuck in a very bad place. Good example someone not knowing any better creates 10 key for a single character but then needs to make corp key since he is CEO and there are no directors in corp or the only ones are on the same account how could anyone get themselves out of that without being able to change a key? The feeling I got from CCP is they were only going to ever allow 10 keys and made them so they could be changed so they could be reused. Now idea of invalidating is great but what if you decided you want to have a key with same APIs etc? Are you say tough you get to just make another one and try to remember what you had? What if they need to keep the key, vCode the same because they don't have a secure way anymore to get the new info to the person that needs the access?

In the end the only ones that can truly solve this are the only ones that haven't posted to this thread and that is CCP. I have a feeling we're not going to get one from them without someone filing a petition/bugreport with the latter probably being the better thing to do. It will need to refer to this thread as well so they get a better understanding of what a problem it is.

Anyway another couple $0.02 ISKs worth of my thoughts on it I'm off to bed.

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

Tonto Auri
Vhero' Multipurpose Corp
#29 - 2011-10-18 15:13:23 UTC
Dragonaire wrote:
Last few comments are great and all but they forget one point you only get 10 key period so what happens when you use them up?

When you invalidate key, it is no longer active. May as well be gone.
I don't see a problem.

Two most common elements in the universe are hydrogen and stupidity. -- Harlan Ellison

Previous page12