EVE Search - Customizable API key update

Check My IP Information

All Channels

EVE Technology Lab

Customizable API key update

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] 2 3 4 5 6 :: one page

Author	Thread Statistics \| Show CCP posts - 37 post(s)

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. EveHQ Character App

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 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. EveHQ Character App
Desmont McCallock	Posted - 2011.07.21 19:16:00 - [5] Originally by: Vessper Thanks, good to know 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] Do we have documentation somewhere on which parameters to pass and how to pass them to the api? --------------------------------------------- EVETycoon Marketing, trading and reprocessing tool.
Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.07.22 04:03:00 - [7] 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. POS-Tracker 3.0 Hosting
Desmont McCallock	Posted - 2011.07.22 07:10:00 - [8] Edited by: Desmont McCallock on 22/07/2011 07:14:26 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 ones we have?
Desmont McCallock	Posted - 2011.07.22 07:28:00 - [9] Edited by: Desmont McCallock on 22/07/2011 07:32:50 @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 Character.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.

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


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 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 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? --------------------------------------- Irdalth Delrar Diplomatic Director Eve University <IVY>
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. EveHQ Character App
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. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.

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

Desmont McCallock	Posted - 2011.07.22 15:01:00 - [26] 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. :)

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] 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.
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? EveHQ Character App



Pages: [1] 2 3 4 5 6 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.