open All Channels
seplocked EVE Technology Lab
blankseplocked Customizable API key update
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2 3 4 5 6

Author Topic

CCP Stillman

Posted - 2011.07.21 11:29:00 - [1]
 

Greetings!

I just want to bring you all an update on the customizable API key system. We’ve decided on a release date now after working out the major kinks in it.

We will roll it onto TQ on August 30th! Note that you will still be able to use your old API keys, but all new API keys will have to be done using the new customizable API key system.
The new API itself is currently deployed to http://apitest.eveonline.com. You can find the key management system at http://supporttest.eveonline.com. We’ll be deploying a new version of that before the weekend, but the current one should work.

We would really appreciate that if you find any bugs that you file a bug report about it or post here. If you decide to file a bug report, please make sure to prefix the title with “API:”, so that I can easily find it.

All feedback/comments/issues are much appreciated. We need to make sure that deploying this to a larger audience works well before going live on TQ, so if you want to start making your application CAK compatible now, that’d be greatly appreciated so that we can have a smooth launch!

But as always, please note that the August 30th date is subject to change if any critical issues arises that would halt the deployment. But with any luck, it'll happen.

Thanks in advance!
Stillman

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.21 12:54:00 - [2]
 

Will the new API Key management update before the weekend provide a method of accessing the account related APIs, namely the Characters.xml.aspx and AccountStatus.xml.aspx? It's just that they seem to be missing from the API lists.


CCP Stillman

Posted - 2011.07.21 13:20:00 - [3]
 

Originally by: Vessper
Will the new API Key management update before the weekend provide a method of accessing the account related APIs, namely the Characters.xml.aspx and AccountStatus.xml.aspx? It's just that they seem to be missing from the API lists.



Should be, at least I know we fixed the absence of AccountStatus.xml.aspx. If not, we'll fix it :)

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.21 13:38:00 - [4]
 

Thanks, good to know Smile

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.


Desmont McCallock
Posted - 2011.07.21 19:16:00 - [5]
 

Originally by: Vessper
Thanks, good to know Smile
OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.

Or multiple rows of xml node <key>, each containing the characterID of each character in the account.

Either this or the list of ID's Vessper suggests, ain't too hard to de-serialize and get the character ID's but no ID'a is a bugger.

Mark Hamill
Amarr
Galactic Waste Management
EVE Trade Consortium
Posted - 2011.07.21 22:31:00 - [6]
 

Edited by: Mark Hamill on 21/07/2011 23:59:52
Do we have documentation somewhere on which parameters to pass and how to pass them to the api?

Nevermind, found it here: Linkage

This does bring up a question tho.

If an app wants to grab the account status or account characters then it'll still have to use the old method with the API key?

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.22 04:03:00 - [7]
 

Edited by: Johnathan Roark on 22/07/2011 04:14:25
How long will both systems work, and will we still be able to make the old style of keys?

Any chance of adding a semi-static api with with the mask for convenience?

Are the keyIDs unique? any risk of two players having two of the same keyID? I'm guessing unique since my first one was 245.

Desmont McCallock
Posted - 2011.07.22 07:10:00 - [8]
 

Edited by: Desmont McCallock on 22/07/2011 11:55:45
Originally by: Mark Hamill
Edited by: Mark Hamill on 21/07/2011 23:59:52
Do we have documentation somewhere on which parameters to pass and how to pass them to the api?

Nevermind, found it here: Linkage

This does bring up a question tho.

If an app wants to grab the account status or account characters then it'll still have to use the old method with the API key?


Works perfectly fine with the new API key system (CAK). They are just not there in the list of API calls a character can make.


Originally by: Johnathan Roark
Edited by: Johnathan Roark on 22/07/2011 04:14:25
How long will both systems work, and will we still be able to make the old style of keys?

Any chance of adding a semi-static api with with the mask for convenience?

Are the keyIDs unique? any risk of two players having two of the same keyID? I'm guessing unique since my first one was 245.


As far as I know they are unique. The real question is, will the keys be nerfed once the CAK gets to business or we get to keep the CAK?

Edit: Wouldn't it be better if we kept the current userID's as CAK keyID's? Is it too hard (technical wise) to do this or it's a good opportunity to clear up the API DB?

Desmont McCallock
Posted - 2011.07.22 07:28:00 - [9]
 

Edited by: Desmont McCallock on 22/07/2011 07:54:51
@Vessper
Looks like the CAK works like this.
- If you set the CAK access to all characters, the Characters.xml.aspx call returns a list of all characters in the account.
- If you set the CAK to any of the characters, the Characters.xml.aspx call returns only that character.

So there is no bug and we just have to add one more call to the apps (a.k.a APIKeyInfo.xml.aspx) to determine the access the CAK has to the available calls.

@CCP Stillman
Both calls to account info (a.k.a. Characters and AccountStatus) are exposed with the CAK. I'm not sure that AccountStatus should be exposed like this (considering that in the current system it is accessed only with the Full APIKey) and should be added in the list of the API calls accessibility.

Found two bugs in CharacterInfo call.
1. Ship related info are returned with station info.
2. CharacterInfo under 'Public Information' returns the 'lastKnownLocation' info when it shouldn't, while the same call under 'Private Information' doesn't contain that info. Calls results should be switched around.

CCP Stillman

Posted - 2011.07.22 13:23:00 - [10]
 

Originally by: Vessper

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.



Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)

CCP Stillman

Posted - 2011.07.22 13:25:00 - [11]
 

Originally by: Johnathan Roark
Edited by: Johnathan Roark on 22/07/2011 04:14:25
How long will both systems work, and will we still be able to make the old style of keys?

Any chance of adding a semi-static api with with the mask for convenience?

Are the keyIDs unique? any risk of two players having two of the same keyID? I'm guessing unique since my first one was 245.


1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.
2. Do you mean something like /api/calllist.xml.aspx? That gives you the access mask for each call, so if I understand your question, that should do what you're asking for
3. They're unique, yes.

CCP Stillman

Posted - 2011.07.22 13:27:00 - [12]
 

Originally by: Desmont McCallock
Edited by: Desmont McCallock on 22/07/2011 11:55:45
Originally by: Mark Hamill
Edited by: Mark Hamill on 21/07/2011 23:59:52
Do we have documentation somewhere on which parameters to pass and how to pass them to the api?

Nevermind, found it here: Linkage

This does bring up a question tho.

If an app wants to grab the account status or account characters then it'll still have to use the old method with the API key?


Works perfectly fine with the new API key system (CAK). They are just not there in the list of API calls a character can make.

This is a bug as a result of the way it was deployed. We'll fix that Cool

CCP Stillman

Posted - 2011.07.22 13:28:00 - [13]
 

Originally by: Desmont McCallock
Wouldn't it be better if we kept the current userID's as CAK keyID's? Is it too hard (technical wise) to do this or it's a good opportunity to clear up the API DB?

It was a design decision not to use userID, because that's potentially sensitive information. This way, it will always be unique for all keys you create. We feel that is better for everybody.

CCP Stillman

Posted - 2011.07.22 13:54:00 - [14]
 

Originally by: Desmont McCallock

@CCP Stillman
Both calls to account info (a.k.a. Characters and AccountStatus) are exposed with the CAK. I'm not sure that AccountStatus should be exposed like this (considering that in the current system it is accessed only with the Full APIKey) and should be added in the list of the API calls accessibility.


Agreed Very Happy

Quote:
1. Ship related info are returned with station info.

This is actually because of the new way that being in a station is handled. When you're in a station, your character is in the station as opposed to your ship with you inside being there. Nice catch
Very Happy
Quote:
2. CharacterInfo under 'Public Information' returns the 'lastKnownLocation' info when it shouldn't, while the same call under 'Private Information' doesn't contain that info. Calls results should be switched around.

I can't reproduce this :(

Irdalth Delrar
EVE University
Ivy League
Posted - 2011.07.22 14:13:00 - [15]
 

Originally by: CCP Stillman
3. They're unique, yes.


As a follow up to that, if I have keyID 1, and delete that key, no one else (including me) will ever have keyID 1, correct? I want to make sure its unique like an auto_increment or something similar.

The main reason I worry is there is no longer a unique identifier between character and account. If I have an account with 3 characters and make a key to give to someone with character #1, then delete two character (lets say #1 and #3) and give them a new key with character #2, they have no way of knowing if I sold the character, deleted the other two, etc, which really just allows people to be sneaky with key's if they want. I know its been stated you don't want to give out userIDs for security reasons, but couldn't you provide an account identifier in the account info api? Something to check if a character is sold or still on the same account?

Desmont McCallock
Posted - 2011.07.22 14:14:00 - [16]
 

Edited by: Desmont McCallock on 22/07/2011 14:18:29
Originally by: CCP Stillman
Originally by: Vessper

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.



Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)


As explained in a previous post
Quote:
Looks like the CAK works like this.
- If you set the CAK access to all characters, the Characters.xml.aspx call returns a list of all characters in the account.
- If you set the CAK to any of the characters, the Characters.xml.aspx call returns only that character.

I don't think this is a bug and should stay as it is.

Example:
The query order logic will be (at least in EVEMon will):
- Query Characters call with given credentials to find to what character's in account the credentials are bound to.

- Query APIKeyInfo call to find the calls the given credentials expose.

So if APIKeyInfo call doesn't contain any characterID, then it means that the given credentials are valid for all characters in account and you have those ID's from the Characters call.

Fade Toblack
Posted - 2011.07.22 14:22:00 - [17]
 

Originally by: CCP Stillman

1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.


This deployment sucks.

On Aug 30th you will change the API.

On Aug 31st say I introduce a new player to Eve. I recommend to the new player that he should go use EveMon/EFT/some other cool tool that uses the API. Unfortunately he can't get it to work as the only API keys he's able to generate don't work in those programs because they haven't released their updates yet (even if all their code changes are done.)

You need to phase this in better.

Aug 30th New API goes live alongside old one. New-style and old-style API keys both work, and BOTH CAN STILL BE GENERATED.

Say 8 weeks later - Oct 25th - generation of old-style API keys is disabled, but existing old-style API still work. This gives people who write apps that use the API to finish bug-fixing and release code that uses the new API keys.

More weeks later - old-style API is disabled completely.

Desmont McCallock
Posted - 2011.07.22 14:26:00 - [18]
 

Edited by: Desmont McCallock on 22/07/2011 14:26:54
Originally by: CCP Stillman
Originally by: Desmont McCallock

2. CharacterInfo under 'Public Information' returns the 'lastKnownLocation' info when it shouldn't, while the same call under 'Private Information' doesn't contain that info. Calls results should be switched around.

I can't reproduce this :(


It's fairly easy. Create a CAK and expose only the CharacterInfo call from the 'Public Information' list.
Wait over a minute, in case you have already made a call to CharacterInfo (I don't know why but there is a delay in returning new result).
Now make the call and you will see the "lastKnownLocation" node in the result although it shouldn't be.

CCP Stillman

Posted - 2011.07.22 14:30:00 - [19]
 

Originally by: Fade Toblack
Originally by: CCP Stillman

1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.


This deployment sucks.

On Aug 30th you will change the API.

On Aug 31st say I introduce a new player to Eve. I recommend to the new player that he should go use EveMon/EFT/some other cool tool that uses the API. Unfortunately he can't get it to work as the only API keys he's able to generate don't work in those programs because they haven't released their updates yet (even if all their code changes are done.)

You need to phase this in better.

Aug 30th New API goes live alongside old one. New-style and old-style API keys both work, and BOTH CAN STILL BE GENERATED.

Say 8 weeks later - Oct 25th - generation of old-style API keys is disabled, but existing old-style API still work. This gives people who write apps that use the API to finish bug-fixing and release code that uses the new API keys.

More weeks later - old-style API is disabled completely.


Very good point. I just talked to Elerhjino, and we'll leave the old-style key generation up for 2 weeks after we release the API update. I hope that will suffice.

CCP Stillman

Posted - 2011.07.22 14:31:00 - [20]
 

Originally by: Desmont McCallock
Edited by: Desmont McCallock on 22/07/2011 14:26:54
Originally by: CCP Stillman
Originally by: Desmont McCallock

2. CharacterInfo under 'Public Information' returns the 'lastKnownLocation' info when it shouldn't, while the same call under 'Private Information' doesn't contain that info. Calls results should be switched around.

I can't reproduce this :(


It's fairly easy. Create a CAK and expose only the CharacterInfo call from the 'Public Information' list.
Wait over a minute, in case you have already made a call to CharacterInfo (I don't know why but there is a delay in returning new result).
Now make the call and you will see the "lastKnownLocation" node in the result although it shouldn't be.

Got it! Was only able to get ship information at first, got the last known location too now. Thanks!

Desmont McCallock
Posted - 2011.07.22 14:44:00 - [21]
 

Edited by: Desmont McCallock on 22/07/2011 14:45:22
Originally by: Fade Toblack
Originally by: CCP Stillman

1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.


This deployment sucks.

On Aug 30th you will change the API.

On Aug 31st say I introduce a new player to Eve. I recommend to the new player that he should go use EveMon/EFT/some other cool tool that uses the API. Unfortunately he can't get it to work as the only API keys he's able to generate don't work in those programs because they haven't released their updates yet (even if all their code changes are done.)

You need to phase this in better.

Aug 30th New API goes live alongside old one. New-style and old-style API keys both work, and BOTH CAN STILL BE GENERATED.

Say 8 weeks later - Oct 25th - generation of old-style API keys is disabled, but existing old-style API still work. This gives people who write apps that use the API to finish bug-fixing and release code that uses the new API keys.

More weeks later - old-style API is disabled completely.



Fade, I share your concerns.

Upon yesterday, I stopped coding whatever I was coding for EVEMon and I started immediately dealing with CAK.
The fact that the CAK is in test server gives us the possibility to debug the changes we have to make and do extensive testing.

My concern is that when CAK deploys, it will be along side with the next phase of Incarna. That means that a new SDD will be available and due to latest practice, CCP doesn't release the SDD in advance.

So in that case the EVEMon Dev Team will have to make a release upon CAK deployment ends and a release when SDD get's available and contains changes that break EVEMon (which it usually does).

If CCP Stillman or CCP in general, can guaranty us that we will have the SDD in time, then from our side we will make all efforts to be ready on the 30th of August.

Of course this doesn't solve everything as EVEMon isn't the only app around.

Edit: was writing these lines before I saw CCP Stillman's reply, so all is good.

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.22 14:46:00 - [22]
 

Originally by: Desmont McCallock
I don't think this is a bug and should stay as it is.

Example:
The query order logic will be (at least in EVEMon will):
- Query Characters call with given credentials to find to what character's in account the credentials are bound to.

- Query APIKeyInfo call to find the calls the given credentials expose.

So if APIKeyInfo call doesn't contain any characterID, then it means that the given credentials are valid for all characters in account and you have those ID's from the Characters call.

Just because you have an alternative API to call doesn't mean that it's not a bug in this one. The APIKeyInfo API should be exactly that, not some partially returned information because the info is available elsewhere.

In fact, characterName, corpID and corpName could be added to the APIKeyInfo for character keys, and have an entry for each valid character the key is used for. If this then provides the same functionality as Characters.xml.aspx, then you only ever need to make the call to APIKeyInfo. I'd much rather see this as it gives you the current access mask and expiry time as well as the basic character info.


Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.07.22 14:50:00 - [23]
 

Just thought I'd put it out here since you ask people to start testing that I'm in the process of converting Yapeal to use the new keys and should be able to start testing within a couple weeks if things go as planned.

Quote:
We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.
I'm with Fade Toblack on this there should be at least a short (couple weeks to month) period when both types can be created and say 3-6 month period when both style keys work with the APIs so that people that are just starting with Eve and those that have been away from it due to RL aren't left in the dark without chance to use the many applications that have been built up around the APIs while they move from the old system to the new.

CCP Stillman

Posted - 2011.07.22 14:50:00 - [24]
 

Originally by: Desmont McCallock

My concern is that when CAK deploys, it will be along side with the next phase of Incarna. That means that a new SDD will be available and due to latest practice, CCP doesn't release the SDD in advance.


Just to be clear, the August 30th launch doesn't change that much in regards to Incarna. You can see what it changes on SISI atm, and as I recall, it's just some extra captain quarters, but don't quote me on it.

But I'll see what I can do to get the SDD out asap before release.

CCP Stillman

Posted - 2011.07.22 14:51:00 - [25]
 

Originally by: Vessper
Originally by: Desmont McCallock
I don't think this is a bug and should stay as it is.

Example:
The query order logic will be (at least in EVEMon will):
- Query Characters call with given credentials to find to what character's in account the credentials are bound to.

- Query APIKeyInfo call to find the calls the given credentials expose.

So if APIKeyInfo call doesn't contain any characterID, then it means that the given credentials are valid for all characters in account and you have those ID's from the Characters call.

Just because you have an alternative API to call doesn't mean that it's not a bug in this one. The APIKeyInfo API should be exactly that, not some partially returned information because the info is available elsewhere.

In fact, characterName, corpID and corpName could be added to the APIKeyInfo for character keys, and have an entry for each valid character the key is used for. If this then provides the same functionality as Characters.xml.aspx, then you only ever need to make the call to APIKeyInfo. I'd much rather see this as it gives you the current access mask and expiry time as well as the basic character info.



I personally think that it's better for the result to be explicit in it's result. So we'll make some tweaks to it, just to avoid any confusion Smile

Desmont McCallock
Posted - 2011.07.22 15:01:00 - [26]
 

Edited by: Desmont McCallock on 22/07/2011 15:34:57
@Vessper
I don't argue with your logic.
I think I used a wrong word in my sentence and should had wrote it as "I don't think this is a bug and could stay as it is." and I apologies for the misconception.

I too prefer the merging of both calls into one but I don't see that happening according to CCP Stillman's latest reply.

Edit:
@CCP Stillman
And before I forgot, yes a list of the access mask for each call, would come in handy. :)

CCP Stillman

Posted - 2011.07.22 15:24:00 - [27]
 

Originally by: Desmont McCallock
Edited by: Desmont McCallock on 22/07/2011 15:08:09
@Vessper
I don't argue with your logic.
I think I used a wrong word in my sentence and should had wrote it as "I don't think this is a bug and could stay as it is." and I apology for the misconception.

I too prefer the merging of both calls into one but I don't see that happening according to CCP Stillman's latest reply.

Edit:
@CCP Stillman
And before I forgot, yes a list of the access mask for each call, would come in handy. :)


Like this? http://apitest.eveonline.com/api/calllist.xml.aspx

Desmont McCallock
Posted - 2011.07.22 15:37:00 - [28]
 

Edited by: Desmont McCallock on 22/07/2011 15:52:34
Originally by: CCP Stillman
Originally by: Desmont McCallock
Edited by: Desmont McCallock on 22/07/2011 15:08:09
@Vessper
I don't argue with your logic.
I think I used a wrong word in my sentence and should had wrote it as "I don't think this is a bug and could stay as it is." and I apology for the misconception.

I too prefer the merging of both calls into one but I don't see that happening according to CCP Stillman's latest reply.

Edit:
@CCP Stillman
And before I forgot, yes a list of the access mask for each call, would come in handy. :)


Like this? http://apitest.eveonline.com/api/calllist.xml.aspx

Nice!!!

Sweeping it as you read this.

Edit:
I know you have them in your TODO list but just wanted to make sure it doesn't get misplaced (scripta manet).

So what needs to be fixed is:
- Returned characterID info of APIKeyInfo call for all characters.
- Set AccountStatus as private information call (update calllist with given accessMask).
- Switching results of CharacterInfo call between public and private info group.
- Revise returned ship info of CharacterInfo call.

After that we are all good to go with CAK (hopefully).

Orpheus Ovid
Posted - 2011.07.22 15:43:00 - [29]
 

Thank you for interacting with the posters!

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.22 16:52:00 - [30]
 

Did someone break the API key generation page? The ability to generate corporate keys has stopped working as it's no longer possible to select Corporation from the Type drop-down, regardless of whether the characters are CEO or not. All my characters now say "Corp" next to them whereas before they said "CEO" (where applicable). Most likely related to that, the CreatePredefined page doesn't want to create corp keys.

Also, some usability points for the API Key generation page:

1. The generate button for the vcode doesn't work.
2. When creating a new key from scratch, the Expiry date is set 1 year into the future. However, when using the CreatePredefined option, the date is set to today's date. Ideally, this should also be set 1 year in the future.
3. Probably more wishful thinking, what are the chances of being able to pass Key Name and vCode data to the CreatePredefined page? Very Happy


Pages: [1] 2 3 4 5 6

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only