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 |
|
Desmont McCallock
|
Posted - 2011.07.22 18:03:00 -
[31]
Originally by: Vessper 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?
Confirming the above findings. Probably they have work in progress.
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.22 21:46:00 -
[32]
Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!
|
|
CCP Stillman
|
Posted - 2011.07.22 22:02:00 -
[33]
Originally by: Marcel Devereux Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!
Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?
|
|
|
CCP Stillman
|
Posted - 2011.07.22 22:03:00 -
[34]
Originally by: Desmont McCallock
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).
Elerhino fixed some of it already. The rest will be fixed Monday.
|
|
|
CCP Stillman
|
Posted - 2011.07.22 22:03:00 -
[35]
Originally by: Vessper 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?
Some of the support site broke during an integration. We'll fix it on monday
|
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.07.22 22:31:00 -
[36]
Originally by: CCP Stillman
Originally by: Vessper 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?
Some of the support site broke during an integration. We'll fix it on monday
Any chance you can also fix the WalletJournal API while you're at it? Still not returning a month's worth of entries despite the numerous bug reports and forum threads describing it. I know it's slightly off-topic but it seems a good opportunity seeing as though we have a dev watching the thread
EveHQ Character App |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.22 22:32:00 -
[37]
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 :)
My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.
Originally by: CCP Stillman
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.
1. I am hoping for a month or so of being able to generate old style keys. This is a big change, needed change, to the api system. 2. Exactly, that will make some things so much easier. 3. Thanks for the clarification.
POS-Tracker 3.0 Hosting |
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.07.22 23:28:00 -
[38]
Originally by: Johnathan Roark
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 :)
My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.
As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.
EveHQ Character App |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.23 01:13:00 -
[39]
Originally by: Vessper
Originally by: Johnathan Roark
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 :)
My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.
As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.
Yes, its not this particular API's place to determine what characters are on what account, but it's purpose is to state what a key has access to. I would be happy with an attribute that says true or false for all characters.
POS-Tracker 3.0 Hosting |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.23 05:09:00 -
[40]
The two new calls aren't setting xml headers, or something along those lines. Firefox is treating them as html pages.
POS-Tracker 3.0 Hosting |
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.23 05:17:00 -
[41]
I've just been looking at the new calllist.xml.aspx API and noticed that there are two rows with name="CharacterInfo". Could they maybe be named name="CharacterInfoPublic" and name="CharacterInfoPrivate" or something as it's confusing with them both having the same name. I notice that in the key creation page to and think it's going to be confusing there as well without some way to separate them beyond the group they are in. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Somerset Mahm
Somer's Omnibus Exploration and Reclamation Cognitive Distortion
|
Posted - 2011.07.23 06:45:00 -
[42]
The wiki still has AssetList being a 23-hour expiry, but it's 6-hour now.
Looking really good so far. --- SOMER Lotteries SOMER Blink - new! SOMER Escrow Services |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.23 07:39:00 -
[43]
Originally by: Somerset Mahm The wiki still has AssetList being a 23-hour expiry, but it's 6-hour now.
Looking really good so far.
Any EVE player can edit evelopedia, edits just need to be approved and it looks like someone (Desmont McCallock) has already fixed it.
POS-Tracker 3.0 Hosting |
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.23 17:37:00 -
[44]
Originally by: CCP Stillman
Originally by: Marcel Devereux Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!
Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?
More like adding this link in the Actions section:
[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]
This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.24 02:44:00 -
[45]
Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID?
POS-Tracker 3.0 Hosting |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.24 05:22:00 -
[46]
I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.
First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.
If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.
Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.
Anyway thought I'd share the above and see what everyone else thinks. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.24 05:33:00 -
[47]
Originally by: Dragonaire I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.
First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.
If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.
Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.
Anyway thought I'd share the above and see what everyone else thinks.
This would do what I was wanting, plus, no schema changes like my suggestion would have required.
Originally by: Johnathan Roark
My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.
As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.
Yes, its not this particular API's place to determine what characters are on what account, but it's purpose is to state what a key has access to. I would be happy with an attribute that says true or false for all characters.
POS-Tracker 3.0 Hosting |
Desmont McCallock
|
Posted - 2011.07.24 08:37:00 -
[48]
Edited by: Desmont McCallock on 24/07/2011 08:37:11
Originally by: Johnathan Roark Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID?
AccountStatus call is under revise. I suggested that it should be added in the list of accessibility and has been accepted. So expect changes for that call after Monday.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.26 03:50:00 -
[49]
Ok with another day of work with APIKeyInfo and the different types of keys I've got a couple more suggestions on changes. The single character keys work find as is with the API as is but corporation and all characters keys aren't as friendly to work with. The corp keys you can work around by using 2 API calls one to APIKeyInfo and another to account/Characters as well so you have the info needed to map from characterID to corporationID but I think there is a better way which I'll get to shortly. The real problem is with all character keys. If you are doing like I do in Yapeal and storing the data directly to a database table which is storing info for multiple accounts you have no way of knowing which characters they belong to. Now for libraries that are single account/char/corp based it's probably no problem as they know all the characters they are working with in Characters can use the key but I think they will also run into some problems when it comes time to save the data that I'm having to face up front.
Now for a simple way to solve the need for 2 API calls for corp keys is to instead of return the characterID return the corporationID directly instead. The type attribute could even be dropped I believe but it could stay.
Now how to deal with all keys isn't so simple. One way would be to add another attribute called something like characterIDs. If this was done I would say type really should be dropped as it no longer useful. It would probably be a good idea to have the attributes that are empty not appear in the XML but the idea of three optional attributes like that is at best just messy.
Another idea would be to have a single attribute named just IDs and have type do it's job with the addition of an "all" or "multiple" option much like what I proposed the other day.
There is one other idea as well which I've decided should be looked at too. I was one of many voices at the start calling for something like the all character keys but I can see the reason the new custom key system originally was proposed without them and just had single character and single corporation keys. It makes for much simpler key management in applications, libraries and I'm sure on the servers as well. It would also simplify calls to char APIs as now if you use all character keys you also have to include the charID so the API knows which one to return the data for. With just single character keys that isn't needed and all the account, char, and corp APIs would be the same and just have keyID and vCode as required parameters.
I believe now is the time to look at making this change while all the third party developers are in the early stages of changing things in their software and the code is still fairly fluid in CCP as well. Anyway I look forward to some feedback from both CCP and another developers on my ideas or maybe someone will have a better idea that solve everything in much cleaner way. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Sulimar Saisima
|
Posted - 2011.07.26 04:58:00 -
[50]
I would like to request that with the launch of the new API system that the login for the API not be linked to the forum. As it currently stands when you plex after trial it cannot login to the forums for 72 hours. This is fine and dandy for me. When you try to login and grab an api key you cannot login to get your api key as the current auth system is tied to the forums and locks you out.
This is with the current 2 key system not the new multi key system being rolled out. Just wanted to hope that the new API system would not have this same issue.
|
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.07.26 10:02:00 -
[51]
Edited by: Hel O''Ween on 26/07/2011 10:05:19 Reporting my findings after a few minutes playing with the test system:
- "Create key" page Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way.
- API URLs Now that the API key basically tells the difference between char and corp data, the distinction between /char/ and /corp/ in the URLs doesn't make sense anymore. Before, we had just a key and need to tell the API via those paths which type of info we'd like to query. This isn't the case with the new system anymore.
Also, the dev blog mentions ...
Quote:
"[...] the new customizable API key system together with the Singularity API server (https://apitest.eveonline.com)."
... and ...
Quote:
"Like this:
http://apitest.eveonline.com/char/CharacterSheet.xml.aspx?keyID=1&vCode=SOSECRETYOUCANTKNOW&characterID=42"
Secure sockets don't work (404 error) for me on the test server. |
|
CCP Stillman
|
Posted - 2011.07.26 10:24:00 -
[52]
Originally by: Hel O'Ween
- "Create key" page Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way.
Good catch!
Originally by: Hel O'Ween
- API URLs Now that the API key basically tells the difference between char and corp data, the distinction between /char/ and /corp/ in the URLs doesn't make sense anymore. Before, we had just a key and need to tell the API via those paths which type of info we'd like to query. This isn't the case with the new system anymore.
While you're technically right, changing that would require a major refactoring and would break backwards compatibility very easily. We'll stick with the smallest change possible to implement this, as we want to make sure everything keeps working when we deploy.
Originally by: Hel O'Ween
Also, the dev blog mentions ...
Quote:
"[...] the new customizable API key system together with the Singularity API server (https://apitest.eveonline.com)."
... and ...
Quote:
"Like this:
http://apitest.eveonline.com/char/CharacterSheet.xml.aspx?keyID=1&vCode=SOSECRETYOUCANTKNOW&characterID=42"
Secure sockets don't work (404 error) for me on the test server.
I'll get somebody to fix that :) |
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.27 16:23:00 -
[53]
CCP Stillman, Any word on getting that link added? The biggest complaint I have with Aura is API key entry. Please add this feature.
|
Desmont McCallock
|
Posted - 2011.07.29 08:35:00 -
[54]
OK. Almost a week has past since the last update and it looks like nothing has changed on the CAK system (except the SSL fix). We are about a month before announced deployment date and time is of essence. Some of us will go on vacations (it's summer time after all) and may be on a tight spot when returned.
So, CCP Stillman, are we there yet?
|
|
CCP Stillman
|
Posted - 2011.07.29 10:17:00 -
[55]
Sorry guys, I've been out sick the last 3 days. We have some changes in the pipeline, which might get deployed today.
|
|
|
CCP Stillman
|
Posted - 2011.07.29 10:31:00 -
[56]
Originally by: Marcel Devereux
Originally by: CCP Stillman
Originally by: Marcel Devereux Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!
Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?
More like adding this link in the Actions section:
[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]
This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.
Discussed this with Elerhino. Sounds like a good idea. We'll see what we can do!
|
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.29 10:52:00 -
[57]
Originally by: CCP Stillman
Originally by: Marcel Devereux
Originally by: CCP Stillman
Originally by: Marcel Devereux Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!
Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?
More like adding this link in the Actions section:
[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]
This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.
Discussed this with Elerhino. Sounds like a good idea. We'll see what we can do!
You rock!
|
Desmont McCallock
|
Posted - 2011.07.29 17:23:00 -
[58]
Edited by: Desmont McCallock on 29/07/2011 17:26:12 So here's an update on the fixing progress of the CAK system.
Originally by: Desmont McCallock
So what needs to be fixed is: - Returned characterID info of APIKeyInfo call for all characters. Fixed. - Set AccountStatus as private information call (update calllist with given accessMask). Not fixed. - Switching results of CharacterInfo call between public and private info group. Not fixed. - Revise returned ship info of CharacterInfo call. Not fixed.
As for the latest (ship info of CharacterInfo call), CCP Stillman replied that those info have been changed to reflect that your character is physically now in a station and not in a ship anymore. To counter that, I thought that this info was about the active ship the character has in the station (s)he is in and not of his(hers) whereabouts (as the "lastKnownLoacation" gives this info). So I strongly believe that those changes should be reverted. I have already added this info in EVEMon [latest snapshot version] using the current API system and it reflects exactly the same info as the EVE client's log-in screen.
Further more,
Originally by: Vessper
1. The generate button for the vcode doesn't work. Fixed. 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. Not fixed.
Originally by: Johnathan Roark Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID? Not answered yet.
Personally, I think "userID" will be redundant with CAK system but it could though be renamed to "accountID".
Originally by: Hel O'Ween
- "Create key" page Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way. Fixed.
Now, on another issue. With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).
This will create an issue with most applications. I will take for example EVEMon as this is the app I'm administrating. Right now EVEMon only monitors Character related calls info (with some minor Corporation calls to MarketOrders and IndustryJobs where characters are in a player's corp and have the right roles). I plan to add some Corp related features in the future and the CAK system will block that ability in the following explained sense. In the current API system a user can give EVEMon the full API key and have calls to both "Character" and "Corporation" related calls, which aren't blocking us in coding in any Corporation feature. Now, with the CAK system, an API key is either 'Character' or 'Corporation' calls bound. This means that if a user would like to monitor both Character and Corporation info (a CEO or Director for example), (s)he will have to enter 2 API keys and so must the app be able to handle them both and separately. The question that pops up is, "Can we have a both, 'Character' and 'Corporation' calls, bound API key in CAK"?, for characters that have CEO or Directors roles. Like adding in the dropdown menu of "Type:" the word 'Both'? I'm afraid that this will be impossible the way the CAK system is currently designed but I'm raising this question to draw attention to that matter. If somebody has a solution on that, I'm more than glad to here it.
|
Desmont McCallock
|
Posted - 2011.07.29 18:10:00 -
[59]
Edited by: Desmont McCallock on 29/07/2011 18:12:01 Original DevBlog, Discussion thread
Originally by: CCO Elerhino
...
One issue is that orders that are issued and processed within the API Orders cache period never appear in the API. To bridge this gap we want to include recently issued orders in the list. We're thinking a week's worth of orders would not only fix the problem but also come in handy if you only want to get the list once a day or every few days.
Another issue is that when an old order gets processed it disappears off the list without any mention of what happened to it. To fix this we'll add an API page, or perhaps an orderID parameter to the Market Order page, so that you can look up the missing order and find out what happened to it.
...
Any solution is better than NO solution. I support this.
Originally by: CCO Elerhino
... A quick note on the deployment schedule - we wanted to get the Market Order fixes out ASAP but currently we don't have a deployment scheduled before the late August one. To take an API build from a development stage to deployment involves a number of people in a number of departments and it's very difficult to get anything like that coordinated during holiday seasons. So most likely you'll have to wait for that one.
Completely understandable.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.07.29 20:49:00 -
[60]
Edited by: Vessper on 29/07/2011 20:56:35
Originally by: Desmont McCallock
So what needs to be fixed is: - Returned characterID info of APIKeyInfo call for all characters. Fixed. - Set AccountStatus as private information call (update calllist with given accessMask). Not fixed. - Switching results of CharacterInfo call between public and private info group. Not fixed. - Revise returned ship info of CharacterInfo call. Not fixed.
As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.
Edit: Link to image
Originally by: Desmont McCallock With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).
This will create an issue with most applications. I will take for example EVEMon as this is the app I'm administrating. Right now EVEMon only monitors Character related calls info (with some minor Corporation calls to MarketOrders and IndustryJobs where characters are in a player's corp and have the right roles). I plan to add some Corp related features in the future and the CAK system will block that ability in the following explained sense. In the current API system a user can give EVEMon the full API key and have calls to both "Character" and "Corporation" related calls, which aren't blocking us in coding in any Corporation feature. Now, with the CAK system, an API key is either 'Character' or 'Corporation' calls, bound API key in CAK"?, for characters that have CEO or Directors roles. Like adding in the dropdown menu of "Type:" the word 'Both'? I'm afraid that this will be impossible the way the CAK system is currently designed but I'm raising this question to draw attention to that matter. If somebody has a solution on that, I'm more than glad to here it.
Yep, I feel your pain on this one! And I think you're correct in that the way the new system is designed will probably exclude the possibility of allowing both character and corporate APIs on the same key. I've been pondering this change over for the past week or so and despite having several possible solutions, I've still not decided on how best to approach it.
EveHQ Character App |
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.29 22:38:00 -
[61]
Edited by: Johnathan Roark on 29/07/2011 22:49:51 Edited by: Johnathan Roark on 29/07/2011 22:39:33
Originally by: Vessper Edited by: Vessper on 29/07/2011 20:56:35
Originally by: Desmont McCallock
So what needs to be fixed is: - Returned characterID info of APIKeyInfo call for all characters. Fixed. - Set AccountStatus as private information call (update calllist with given accessMask). Not fixed. - Switching results of CharacterInfo call between public and private info group. Not fixed. - Revise returned ship info of CharacterInfo call. Not fixed.
As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.
I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
Also, the contract api seems to be working, I have no contracts so I get no data. AccountStatus, userID is still returned, I'm hoping it stays in some form.
PS. I want an employment history API, its in evegate in a very tempting format to sc****
POS-Tracker 3.0 Hosting |
Desmont McCallock
|
Posted - 2011.07.30 06:32:00 -
[62]
Edited by: Desmont McCallock on 30/07/2011 06:38:37
Originally by: Vessper
As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.
By the time I was writing that lines it was either not there or I missed it completely. Never the less I updated my post and will whenever something in the list get fixed.
Originally by: Johnathan Roark
I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
I was too concerned about that and unfortunately the "screenshot" thingy is going to come back.
On another note, whenever I go update my api key info a new code is generated. CCP Stillman, can you have a look at that?
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.30 14:20:00 -
[63]
I like everyone else have been thinking on the old two key system vs the new custom key one that is coming. I'm sure in one form or another we all used some way of associating userID to APIKeys and from there to the characters and corporations. So we all had some like userID[1] -> APIKeys[2] -> characters[3] -> corporations[3] but now there are currently 3 types of keys with three different associations. keyID[x] -> character[1] keyID[x] -> corporation[1] keyID[x] -> characters[1-3] For most libraries/applications 'x' is one but there is no reason it has to be except it makes it easier for us as developers and for our users to administrate the keys. There is a userID (accountID) indirect relationship too still but it only has some meaning in the last case and is very weak. Now what I found useful while trying to decide what needs to be changed in my code is to think about the last case but with 'x' equal to number of APIs in the mask and how I'd have to change things to make that possible and how it would work.
Since I'm using a database to store the relationships I'm going to end up with a key table for all the keys, a character table for all the chars, a corporation table for the corps, and one or more tables to link the keys with the characters and corporations. It really will be easier to work with in the end because of the shorter relationship tree but it will take a lot of work on my part to remove the old implied two key relationships that were in my code.
Hopeful some of you will find the above useful in understanding the problem and it will help clarify your thinking like it did for me and lead you to the changes you'll needed to make. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.30 15:44:00 -
[64]
Quote: Personally, I think "userID" will be redundant with CAK system but it could though be renamed to "accountID".
That would work for me and better describe what it is now. It would also help maybe keep from confusing old info on the API with the new for people when trying to learn more about the APIs.
Quote: With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).
I understand where you're coming from on this one but as I stated in the above post if you really start thinking about and changing things to work with multiple keys it a much more flexible system which of course is part of the problem It will require managing more than one key especially if you do want to monitor more than one corp but for most people with one account they should only need two keys, one for all chars and another for a corp. Even in my case with a couple accounts I'd only need like four keys, 2 * all chars, 1 for main corp and another for alt corp since all my chars are in only 3 corps and one is in an inactive corp I don't monitor. That is of course if I decided to use the new stuff you've been adding to EveMon which I not really now since I'm usually running Linux and use Gtkevemon Mind you I was thinking of both applications as well is my own project when I asked for a single key for all the characters on an account but now I'm leaning more to not having that but just single char and corp keys because it is a much cleaner system to work with if a bit more complex to admin.
Quote: I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
I'm with Johnathan on this we need a way to tell. There's lot of work for all the developers both inside and outside CCP being done and there are so many great things about the API changes being made it would be a pity if this issue ends up leaving an overall bad taste in all of the third party developers' mouths because we have to take flack from our end users on this regression. It would be very easy to solve by simple having the type not just return 'character' or 'corporation but 'multiple' or 'all' as well in APIKeyInfo for all character keys. I know you have to have some way to tell them apart internally at CCP to have the character APIs require us to include characterID parameter when using them.
Quote: PS. I want an employment history API, its in evegate in a very tempting format to sc****
This would be nice and be one more step along the path you've already started on to make public info you can get in the game also through the API.
One bug I've noticed is when I go to edit one of my keys it always fills in the Verification Code with a new random value instead of pre-filling with the old value. This kind of makes the generate key link worthless IMHO anyway On creating a new key pre-filling with a new random code would probably be good but not when trying to update it. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.30 19:45:00 -
[65]
Edited by: Johnathan Roark on 30/07/2011 19:47:01
Originally by: Desmont McCallock Edited by: Desmont McCallock on 30/07/2011 07:27:13
Originally by: Vessper
As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.
By the time I was writing that lines it was either not there or I missed it completely. Never the less I updated my post and will whenever something in the list get fixed.
Yea, it did that to me when I updated a key, but on a new key it worked fine, hoping its just not as instant as we would like when updating a key.
Originally by: Desmont McCallock
Edit: I could still query the AccountStatus call although I had the call restricted. So, we are adding another thing on the TO BE FIXED list.
Originally by: Johnathan Roark
I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
I was too concerned about that and unfortunately the "screenshot" thingy is going to come back.
On another note, whenever I go update my api key info a new code is generated. CCP Stillman, can you have a look at that?
Edit2: Shouldn't the 'Contracts' call be at the "Account and Market" group (I think they are market related after all) ?
Hopefully a fix for both of these is introduced prior to deployment. If not, I see the old style keys being used for a lot longer then they should be.
POS-Tracker 3.0 Hosting |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.30 19:55:00 -
[66]
Btw, what is the point of the characters call now? I suggest depreciating it and remove it when you remove generation of old style keys.
POS-Tracker 3.0 Hosting |
Ryomanni
Red Frog Investments
|
Posted - 2011.08.01 04:33:00 -
[67]
To put it lightly, there are some excited frogs at the announcement of a contract API.
I had an opportunity to try the contracts.xml.aspx page today, and based on a first look at the XML it should provide much of what Red Frog Freight required for improving our internal and external software.
As a result of this first impression, there are some details and questions I compiled if someone is able to answer or consider the following:
Q. Will the contracts results include a weeks worth of contracts, rather than just outstanding and in progress? It would make it easier to record the contracts that are finished, failed, or rejected.
Q. Regarding the recent dev blog post, "We'll also have a separate page or a contractID parameter so that you can look up a single contract." - Will that work on finished contracts?
Q. I see an approximate one hour cachedUntil time on the test server data. Is it possible this cached time could be lessened so new contracts can be recorded more quickly?
Q. Does the "title" element of the XML hold the user defined contract description?
Q. I noticed there are contracts that have a dateAccepted value even though they have a status of "Outstanding" - should that be a blank string like the dateCompleted value is?
Q. Will there be any change to the "showContract" IGB JavaScript method so only a contractID is required, instead of also having to supply the solarSystemID? And if not, could each contract API row also include a solarSystemID (this would save having to look up the solarsystemID of the startStationID in the data dump).
I look forward to parsing the XML and testing further in the coming days, so please let me know if there is more I can do to assist in testing before it goes live.
Ryo
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.01 15:32:00 -
[68]
So I thought of something while looking at the XML for APIKeyInfo to make a new XSD schema for it. With all the changes from custom keys and added APIs etc shouldn't the version on <eveapi version="2"> be changed to '3'? It probably could have been changed before now but with as big of change as custom keys is I think it's important to reflect that in the version. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.02 13:14:00 -
[69]
Edited by: Hel O''Ween on 02/08/2011 13:14:57
Originally by: Desmont McCallock
Personally, I think "userID" will be redundant with CAK system but it could though be renamed to "accountID".
My application heavily relies on the userID (or accountID). It's a simple and clean way of associating (old) corp data with a character who has undergone one or more corp changes.
Originally by: Desmont McCallock
Now, on another issue. With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).
[...] Now, with the CAK system, an API key is either 'Character' or 'Corporation' calls bound. This means that if a user would like to monitor both Character and Corporation info (a CEO or Director for example), (s)he will have to enter 2 API keys and so must the app be able to handle them both and separately.
Spot on. I'm facing this very problem right now.
Quote:
The question that pops up is, "Can we have a both, 'Character' and 'Corporation' calls, bound API key in CAK"?, for characters that have CEO or Directors roles. Like adding in the dropdown menu of "Type:" the word 'Both'? I'm afraid that this will be impossible the way the CAK system is currently designed but I'm raising this question to draw attention to that matter.
You're right. It is not possible atm, but from a design perspective, CAK should have no issues handling it, if I'm not mistaken. Just make sure that the flags in calllist.xml (suggestion: to bring that file name in line with other API calls, make it CallList.xml) are unique. This is not the case now, but should be doable. It seems that CAK does a simple If accessMaskPassed AND accessMaskMemberTrackingCorp = TRUE kind of check. With unique access masks, nothing needs to be changed there. -- EVEWalletAware - an offline wallet manager |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.02 13:19:00 -
[70]
Originally by: Johnathan Roark Edited by: Johnathan Roark on 30/07/2011 20:09:38 Btw, what is the point of the characters call now? I suggest depreciating it and remove it when you remove generation of old style keys.
Isn't it the same as before? Given an "All Chars" key, you retrieve the chars info (=charID, charName etc.) associated with that key. -- EVEWalletAware - an offline wallet manager |
|
Desmont McCallock
|
Posted - 2011.08.02 13:38:00 -
[71]
Originally by: Hel O'Ween
Originally by: Johnathan Roark Edited by: Johnathan Roark on 30/07/2011 20:09:38 Btw, what is the point of the characters call now? I suggest depreciating it and remove it when you remove generation of old style keys.
Isn't it the same as before? Given an "All Chars" key, you retrieve the chars info (=charID, charName etc.) associated with that key.
Johnathan has a point as APIKeyInfo and Characters calls return the same data with the exception that APIKeyInfo returns also the "accessMask".
Yes the problem would be solved if each call had its unique 'accessMask' but the question that pops up is "how high will that number go?". Is 64bit enough or we will end up with 128bit?
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.02 15:40:00 -
[72]
I did some quick math let us look at doing combined keys masks. The char/account key currently uses 26 bits and corp uses 23 bits which with a 64 bit mask would leave only 15 bits or to put it another way there could only be 15 more APIs added between all 3 of the API types. There also is the issue with signed vs unsigned integer so to not have problems there you end up with 14 APIs more. A 128 bit mask is possible but even most DBs don't work well with them and a lot of programming languages already can have problems with 64 bits on 32 bit OS.
Now let us look at doing things without any combined keys. Char/account currently uses 26 bits leaving 5(signed)/6(unsigned) more with 32 bit and 37/38 with 64 bit. Corp would have 8/9 with 32 bit and 40/41 with 64 bit.
So to sum up in the short run combined keys makes the conversion easier for us as third parties but since CCP has already spent the time on their end going to other way in their design it'll come back to bite you once they have a need to expand beyond what they allow. Just think if we ever get alliance APIs or something else how limited it would end up being. Believe me I feel your pain as I'm running into several problem myself moving to a multiple key system but I know in the end it'll work long into the future no matter what changes in the APIs too. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.02 16:28:00 -
[73]
Originally by: Desmont McCallock
Yes the problem would be solved if each call had its unique 'accessMask' but the question that pops up is "how high will that number go?". Is 64bit enough or we will end up with 128bit?
The 64 vs. 128 bit (integer) is just a presentation issue, you could equally pass it as a "001001" type of string or a type ("structure" in C, I think) or whatever is best in your language.
Originally by: Dragonaire
So to sum up in the short run combined keys makes the conversion easier for us as third parties but since CCP has already spent the time on their end going to other way in their design it'll come back to bite you once they have a need to expand beyond what they allow.
I don't think it makes conversion easier (at least not for me). I think more about the future an usability. Players can't even handle Limited/Full API keys (and the ingame roles needed for those) now. Guess how that turns out if they need to juggle with multiple keys for char/corp and multiple access masks. Also, I'm an oldtimer and whenever I encounter situations where two of the same could have been handled with one of it + <brain>, I feel the pain. -- EVEWalletAware - an offline wallet manager |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.02 23:09:00 -
[74]
Edited by: Johnathan Roark on 02/08/2011 23:12:51
Originally by: Desmont McCallock
Originally by: Hel O'Ween
Originally by: Johnathan Roark Edited by: Johnathan Roark on 30/07/2011 20:09:38 Btw, what is the point of the characters call now? I suggest depreciating it and remove it when you remove generation of old style keys.
Isn't it the same as before? Given an "All Chars" key, you retrieve the chars info (=charID, charName etc.) associated with that key.
Johnathan has a point as APIKeyInfo and Characters calls return the same data with the exception that APIKeyInfo returns also the "accessMask".
Yes the problem would be solved if each call had its unique 'accessMask' but the question that pops up is "how high will that number go?". Is 64bit enough or we will end up with 128bit?
Its not really a problem and I do not see what access mask have to do with phasing out characters. I just don't see the point in having two apis that have almost an identical purpose. Even single character keys return the same structure, they only return the one character. Also, characters doesn't have an access mask, but you really wouldn't want it to for its original purpose. I just think it would save ccp some resources if it went away at some point and we really should be calling APIKeyInfo to verify access mask.
I would still love to see a response on my question of telling the difference between 'all' and single character keys for accounts that only have one character.
I also want to bring up the employment history api, seems ccp already has something doing mostly what I am looking for, just that scraping evegate is a no-no.
POS-Tracker 3.0 Hosting |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.03 10:55:00 -
[75]
Here's a bad bug that I just noticed: if you click the "Update" link for an already created key on the API keys summary page, the old vCode you set when generating the key for the first time, will be overwritten with a new, random key.
So, if you just want to add/remove some APIs from the key and click "Submit" without paying attention to the (changed) vCode, you also changed your vCode that way. -- EVEWalletAware - an offline wallet manager |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.03 11:16:00 -
[76]
Originally by: Johnathan Roark
I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
Found a "feature" (and this is why we need to be able to distinguish between those two) to tell an all char key appart from a single char key: Try querying the AccountBalance.xml.aspx with a key for a single char and one for all chars.
For your convenience:
https://apitest.eveonline.com/char/AccountBalance.xml.aspx?keyID=<mykey>&vCode=<mycode>
It returns the accountbalance for a single, but this error for an All Char key:
Quote:
<eveapi version="2"><currentTime>2011-08-03 11:08:17</currentTime><error code="105">Invalid characterID.</error><cachedUntil>2011-08-03 11:13:17</cachedUntil></eveapi>
In order to query the account balance for one of those chars, you need to pass another parameter: &characterID=<char ID> -- EVEWalletAware - an offline wallet manager |
Desmont McCallock
|
Posted - 2011.08.03 13:25:00 -
[77]
@Hel O'Ween
Originally by: Hel O'Ween Edited by: Hel O''Ween on 03/08/2011 11:23:42 Here's a bad bug that I just noticed: if you click the "Update" link for an already created key on the API keys summary page, the old vCode you set when generating the key for the first time, will be overwritten with a new, random key.
So, if you just want to add/remove some APIs from the key and click "Submit" without paying attention to the (changed) vCode, you also changed your vCode that way.
Looks like you are not following this thread very closely, as it has been mentioned already.
Originally by: Desmont McCallock
On another note, whenever I go update my api key info a new code is generated. CCP Stillman, can you have a look at that?
@Johnathan
Originally by: Desmont McCallock
Johnathan has a point as APIKeyInfo and Characters calls return the same data with the exception that APIKeyInfo returns also the "accessMask".
This was my comment on your post.
Originally by: Desmont McCallock
Yes the problem would be solved if each call had its unique 'accessMask' but the question that pops up is "how high will that number go?". Is 64bit enough or we will end up with 128bit?
This was for Hel O'Ween's post.
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.03 15:46:00 -
[78]
Originally by: Desmont McCallock @Hel O'Ween
Originally by: Hel O'Ween Edited by: Hel O''Ween on 03/08/2011 11:23:42 Here's a bad bug that I just noticed: if you click the "Update" link for an already created key on the API keys summary page, the old vCode you set when generating the key for the first time, will be overwritten with a new, random key.
So, if you just want to add/remove some APIs from the key and click "Submit" without paying attention to the (changed) vCode, you also changed your vCode that way.
Looks like you are not following this thread very closely, as it has been mentioned already.
Duh ... sorry. You made me lazy with your summary and Fixed/Resolved. -- EVEWalletAware - an offline wallet manager |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.03 16:20:00 -
[79]
The Market Order API doesn't seem to work for me on the test server. It now returns the same error that we currently see occasional on TQ for the wallet journal API:
Quote:
<eveapi version="2"> <currentTime>2011-08-03 16:17:09</currentTime> <error code="0">General Error: Scotty the docking manager heard you were talking **** about him behind his back and refuses to service your request.</error> <cachedUntil>2011-08-03 17:17:09</cachedUntil> </eveapi>
-- EVEWalletAware - an offline wallet manager |
Desmont McCallock
|
Posted - 2011.08.03 21:32:00 -
[80]
Originally by: Hel O'Ween [Added
Oh, and while we're at it: it would be nice if the Access Mask textbox would allow me to paste in a number.
Just use https://supporttest.eveonline.com/api/key/CreatePredefined/"youraccessMask"
|
|
Desmont McCallock
|
Posted - 2011.08.03 21:48:00 -
[81]
Edited by: Desmont McCallock on 03/08/2011 21:49:24
Originally by: Hel O'Ween
Originally by: Johnathan Roark
I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
Found a "feature" (and this is why we need to be able to distinguish between those two) to tell an all char key appart from a single char key: Try querying the AccountBalance.xml.aspx with a key for a single char and one for all chars.
For your convenience:
https://apitest.eveonline.com/char/AccountBalance.xml.aspx?keyID=<mykey>&vCode=<mycode>
It returns the accountbalance for a single, but this error for an All Char key:
Quote:
<eveapi version="2"><currentTime>2011-08-03 11:08:17</currentTime><error code="105">Invalid characterID.</error><cachedUntil>2011-08-03 11:13:17</cachedUntil></eveapi>
In order to query the account balance for one of those chars, you need to pass another parameter: &characterID=<char ID>
Confirmed.
|
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.04 01:24:00 -
[82]
Whether the key is generated for the entire account should probably be part of the access mask. If my app needs to know all of the characters on the account as part of a background-check thing, how can I tell if that user actually only has 1 toon on their account or if they only made the key for one toon? ------------
EVE 3rd-Party Shutdown Party |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.04 09:55:00 -
[83]
Originally by: Kronus Heilgar [...] how can I tell if that user actually only has 1 toon on their account or if they only made the key for one toon?
See the post above yours. -- EVEWalletAware - an offline wallet manager |
|
CCP Stillman
|
Posted - 2011.08.04 11:10:00 -
[84]
Originally by: Hel O'Ween Edited by: Hel O''Ween on 04/08/2011 10:14:28
Originally by: Kronus Heilgar [...] how can I tell if that user actually only has 1 toon on their account or if they only made the key for one toon?
See the post above yours.
To add to my findings re. AccountBalance.xml.aspx: passing the &characterID=<char> parameter also works for a single char key. This at least saves us from "guessing" which parameters to pass (for that API). As far as I can tell, this is true for other API calls, too. Tried it with wallet journal, wallet transaction and it did work, market orders API didn't work either way, Scotty kept insulting me.
Scotty is in a bad mood. Don't take is personally
|
|
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.05 04:24:00 -
[85]
Originally by: CCP Stillman
Originally by: Hel O'Ween Edited by: Hel O''Ween on 04/08/2011 10:14:28
Originally by: Kronus Heilgar [...] how can I tell if that user actually only has 1 toon on their account or if they only made the key for one toon?
See the post above yours.
To add to my findings re. AccountBalance.xml.aspx: passing the &characterID=<char> parameter also works for a single char key. This at least saves us from "guessing" which parameters to pass (for that API). As far as I can tell, this is true for other API calls, too. Tried it with wallet journal, wallet transaction and it did work, market orders API didn't work either way, Scotty kept insulting me.
Scotty is in a bad mood. Don't take is personally
Whoops, sorry for the double post. I guess I read through the entire forum except the post above mine :S
Considering that you have implemented a system that blocks IPs that generate API errors though, I find it bad form to force people to generate errors in order to determine whether or not the key is account-wide. Kind of like it's bad form to force people to generate errors in order to determine if an ID belongs to a corporation or character. ------------
EVE 3rd-Party Shutdown Party |
|
CCP Stillman
|
Posted - 2011.08.05 10:02:00 -
[86]
Originally by: Kronus Heilgar
Originally by: CCP Stillman
Originally by: Hel O'Ween Edited by: Hel O''Ween on 04/08/2011 10:14:28
Originally by: Kronus Heilgar [...] how can I tell if that user actually only has 1 toon on their account or if they only made the key for one toon?
See the post above yours.
To add to my findings re. AccountBalance.xml.aspx: passing the &characterID=<char> parameter also works for a single char key. This at least saves us from "guessing" which parameters to pass (for that API). As far as I can tell, this is true for other API calls, too. Tried it with wallet journal, wallet transaction and it did work, market orders API didn't work either way, Scotty kept insulting me.
Scotty is in a bad mood. Don't take is personally
Whoops, sorry for the double post. I guess I read through the entire forum except the post above mine :S
Considering that you have implemented a system that blocks IPs that generate API errors though, I find it bad form to force people to generate errors in order to determine whether or not the key is account-wide. Kind of like it's bad form to force people to generate errors in order to determine if an ID belongs to a corporation or character.
APIKeyInfo.xml.aspx contains a list of all characters you can query
|
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.05 10:42:00 -
[87]
Originally by: CCP Stillman APIKeyInfo.xml.aspx contains a list of all characters you can query
I think what most people are trying to get at is a simple way of finding ALL characters on the account, irrespective of whether the API key is for one or all characters. If the API key is set up for access to the data of only one character, APIKeyInfo.xml.aspx only shows the one character, as does Characters.xml.aspx.
Two possible ways this could be done:
1. Characters.xml.aspx shows all characters on the account, those that are accessible by the API key and also those that aren't. 2. APIKeyInfo.xml.aspx (or Characters.xml.aspx for that matter) adds another field indicating the number of characters created on the account. This would show if there are any additional characters but not disclose their IDs or names.
Personally, I'd prefer the first option but whatever is easier.
Also, confirming that clicking the update link on the API Key index page resets the vCode to some random string, which it clearly shouldn't.
EveHQ Character App |
Sable Blitzmann
Minmatar Massively Dynamic
|
Posted - 2011.08.05 17:53:00 -
[88]
Did you ever fix the permissions? I remember when the dev blog went up, people with roles in-game were not able to get the same information from the new corp APIs. IE: Directors accessing member tracking and killmails for the corp, accountants not able to access the corp wallet API, among other things. These were restricted to only the CEO.
If these haven't been ironed out yet, THEY ABSOLUTELY MUST BE before launch. =)
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.05 22:37:00 -
[89]
Originally by: Vessper
Originally by: CCP Stillman APIKeyInfo.xml.aspx contains a list of all characters you can query
I think what most people are trying to get at is a simple way of finding ALL characters on the account, irrespective of whether the API key is for one or all characters. If the API key is set up for access to the data of only one character, APIKeyInfo.xml.aspx only shows the one character, as does Characters.xml.aspx.
Two possible ways this could be done:
1. Characters.xml.aspx shows all characters on the account, those that are accessible by the API key and also those that aren't. 2. APIKeyInfo.xml.aspx (or Characters.xml.aspx for that matter) adds another field indicating the number of characters created on the account. This would show if there are any additional characters but not disclose their IDs or names.
Personally, I'd prefer the first option but whatever is easier.
Also, confirming that clicking the update link on the API Key index page resets the vCode to some random string, which it clearly shouldn't.
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Originally by: Sable Blitzmann Did you ever fix the permissions? I remember when the dev blog went up, people with roles in-game were not able to get the same information from the new corp APIs. IE: Directors accessing member tracking and killmails for the corp, accountants not able to access the corp wallet API, among other things. These were restricted to only the CEO.
If these haven't been ironed out yet, THEY ABSOLUTELY MUST BE before launch. =)
I'm rather sure they changed it so directors can generate corporation keys. I hope it remains so only CEOs and directors can generate keys. If the POS guy needs a key for starbases, he can ask his ceo or a director for one.
POS-Tracker 3.0 Hosting |
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.06 00:59:00 -
[90]
Originally by: CCP Stillman
APIKeyInfo.xml.aspx contains a list of all characters you can query
Yes, it does, but there still isn't a way to determine whether the API key is for the whole account or for a single character WITHOUT generating an API error. Please note that the only reason I have a problem with this is because you block IPs that generate errors.
I have an application, and I want to limit it to ONE account per EVE account. With the old system I could do this by just tying each account to a specific userID. With the new system, a player could generate 3 different API keys for a single account, then register on my application using those three different keys (since I can no longer see userID). I can fix this problem by requiring API keys that people sign up with to be account-wide keys; however, this means I need a simple way to check if the key is account-wide or not, WITHOUT generating an API error.
Originally by: Vessper
Originally by: CCP Stillman APIKeyInfo.xml.aspx contains a list of all characters you can query
Two possible ways this could be done:
1. Characters.xml.aspx shows all characters on the account, those that are accessible by the API key and also those that aren't. 2. APIKeyInfo.xml.aspx (or Characters.xml.aspx for that matter) adds another field indicating the number of characters created on the account. This would show if there are any additional characters but not disclose their IDs or names.
Personally, I'd prefer the first option but whatever is easier.
My personal opinion is that the easiest and cleanest way would be to simply add this true/false "account-wide" field as part of the access mask. ------------
EVE 3rd-Party Shutdown Party |
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.06 06:37:00 -
[91]
I see a couple people asking that the access mask include something to say if it's a single or multiple char key but that's not the way to do it IMHO anyway. It makes much more sense to have type have one (or more) additional values. If it was added to mask you'd have to check 2 things to figure out what 'type' of key you have which just doesn't make sense at all. Having type return 'Character', Characters', 'Corporation', etc is much more logical and leaves more room to expand on key types and new APIs without needing to go to larger bitmap for access mask.
As I've already stated and others have as well if there isn't a way to tell if a key is telling the 'true' about how many characters are on a account than it will have failed in a very large way. I'm fine with it just letting people know there are other characters which the above would do and let the parties involved work it out if a multiple character key is going to be required or given. I just don't see why this even needed to come up really because how could anyone at CCP thought it would be accepted by anyone to take away something that has existed every since the APIs came out. It just isn't going to be accepted by any of the developers or the player base either. CCP is really out of touch with everyone else on this. I know there isn't any technical reason for it since the webpage where you can view your keys already shows under the character column 'all' for them so not providing the same information in the API is just ridiculous. |
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.06 10:20:00 -
[92]
Originally by: Dragonaire I see a couple people asking that the access mask include something to say if it's a single or multiple char key but that's not the way to do it IMHO anyway. It makes much more sense to have type have one (or more) additional values. If it was added to mask you'd have to check 2 things to figure out what 'type' of key you have which just doesn't make sense at all. Having type return 'Character', Characters', 'Corporation', etc is much more logical and leaves more room to expand on key types and new APIs without needing to go to larger bitmap for access mask.
Yep I agree with this now after thinking about it some more. Maybe "Multi", "Single" and "Corp" types. Good call good call.
He's also right about the high level of failure if there is no proper way to deal with this (shouldn't have to find workarounds for a system that's supposed to fix the problems, not cause new ones). |
Desmont McCallock
|
Posted - 2011.08.06 12:51:00 -
[93]
Edited by: Desmont McCallock on 06/08/2011 12:54:38
In line with Dragonaire's thoughts, I think the solution lies already there in the CAK structure. Returning values of "type" could be the exact variables you set when you create the key, aka 'All', 'Character', 'Corporation'. So when "type" returns something else than 'All' it means that the key is a character restricted one.
Edit: Btw, I think the 'key' row should also return the accountID (userdID) to make the account tying of multi api keys possible.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.06 13:59:00 -
[94]
Originally by: Desmont McCallock Edited by: Desmont McCallock on 06/08/2011 12:54:38
In line with Dragonaire's thoughts, I think the solution lies already there in the CAK structure. Returning values of "type" could be the exact variables you set when you create the key, aka 'All', 'Character', 'Corporation'. So when "type" returns something else than 'All' it means that the key is a character restricted one.
Yes, this is exactly what we need.
Originally by: Desmont McCallock
Edit: Btw, I think the 'key' row should also return the accountID (userdID) to make the account tying of multi api keys possible.
I would love that. It would fix all the issues I am concerned about with my website.
POS-Tracker 3.0 Hosting |
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.06 17:46:00 -
[95]
Edited by: Kronus Heilgar on 06/08/2011 17:51:00 I think I found a bug with the MailMessages.xml.aspx call. It's returning very old evemails, not the 50 newest ones as specified. Also, the "fromID" feature that is available in the old version for walking back is broken as well.
Looks like SOMEBODY (I'm not going to say who, but I think you know him very very well) forgot an "ORDER BY" in their SQL. ------------
EVE 3rd-Party Shutdown Party |
Elojs
Gallente Corp 42
|
Posted - 2011.08.07 05:34:00 -
[96]
It's probably far too late in the dev cycle for this. But...
https://api.eveonline.com/system/Access.xml.aspx?vCode=<generated key>&preconfigured=<mask>
returning whether the key satisfies all the levels required, i.e. 'Access Granted', and if not returns an appropriate error like 'Access denied', 'Expired API Key' or 'Invalid API Key'. Might this be put on the boards? Basically, verifying the access level granted before hitting the API server with requests that will generate errors until the problem is detected.
Or, if it's on here somewhere and I missed it...sorry.
Sounds really good otherwise. Keep it up!
|
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.07 06:39:00 -
[97]
Originally by: Elojs Edited by: Elojs on 07/08/2011 05:59:31 Edited by: Elojs on 07/08/2011 05:57:59 It's probably far too late in the dev cycle for this. But...
https://api.eveonline.com/system/Access.xml.aspx?vCode=<generated key>&preconfigured=<mask>
returning whether the key satisfies all the levels required, i.e. 'Access Granted', and if not returns an appropriate error like 'Access denied', 'Expired API Key' or 'Invalid API Key', or even a bitmask that identifies which specific access types fail. Might this be put on the boards? Basically, verifying the access level granted before hitting the API server with requests that will generate errors until the problem is detected.
My thought here is that the third-party who receives a key can verify the key grants the access needed without generating an error on the API server.
Or, if it's on here somewhere and I missed it...sorry.
Sounds really good otherwise. Keep it up!
Just use this: http://apitest.eveonline.com/account/APIKeyInfo.xml.aspx?keyID=x&vCode=VERYVERYSECRET That gives you the access mask, then just do a bitwise "AND" with the access mask of everything you need, and if the result = the access mask you need then you know it's good.
e.g. Using the APIKeyInfo.xml.aspx call I find that the API the user submits has access mask "6298113". I want to be able to pull journal entries from their API; using the CallList api call I know that the access mask I need for that is "2097152". So, if I'm using PHP for example, I do:
Quote: $given = 6298113; $needed = 2097152; $result = $given & $needed; if($result == $needed) return true;
Or something like that. ------------
EVE 3rd-Party Shutdown Party |
Elojs
Gallente Corp 42
|
Posted - 2011.08.07 13:39:00 -
[98]
Edited by: Elojs on 07/08/2011 13:45:30 Edited by: Elojs on 07/08/2011 13:42:14
Originally by: Kronus Heilgar
Originally by: Elojs Edited by: Elojs on 07/08/2011 05:59:31 Edited by: Elojs on 07/08/2011 05:57:59 It's probably far too late in the dev cycle for this. But...
https://api.eveonline.com/system/Access.xml.aspx?vCode=<generated key>&preconfigured=<mask>
returning whether the key satisfies all the levels required, i.e. 'Access Granted', and if not returns an appropriate error like 'Access denied', 'Expired API Key' or 'Invalid API Key', or even a bitmask that identifies which specific access types fail. Might this be put on the boards? Basically, verifying the access level granted before hitting the API server with requests that will generate errors until the problem is detected.
My thought here is that the third-party who receives a key can verify the key grants the access needed without generating an error on the API server.
Or, if it's on here somewhere and I missed it...sorry.
Sounds really good otherwise. Keep it up!
Just use this: http://apitest.eveonline.com/account/APIKeyInfo.xml.aspx?keyID=x&vCode=VERYVERYSECRET That gives you the access mask, then just do a bitwise "AND" with the access mask of everything you need, and if the result = the access mask you need then you know it's good.
e.g. Using the APIKeyInfo.xml.aspx call I find that the API the user submits has access mask "6298113". I want to be able to pull journal entries from their API; using the CallList api call I know that the access mask I need for that is "2097152". So, if I'm using PHP for example, I do:
Quote: $given = 6298113; $needed = 2097152; $result = $given & $needed; if($result == $needed) return true;
Or something like that.
Thanks, didn't understand APIKeyInfo.xml.aspx. Bitwise AND's, however, I've had for 30 years.
I've looked it over, and it's exactly what I was worried about. I feel dumb for missing it in the blogs, and smart that I thought it up myself. As well, it answers the other question brewing. Since the characterID is included with APIKeyInfo.xml.aspx's response, we can access the image server from there.
I think though I'd do it the other way. Take a all sections, all items mask, then XOR with a mask of access I don't need, then XOR that with the access mask received from the player, at that point, if it's zero, no problem. Otherwise, OR's with the other access masks would indicate exactly which access has been left off the key.
Very cool. Elojs
|
Elojs
Gallente Corp 42
|
Posted - 2011.08.07 15:20:00 -
[99]
Another thought, would it be possible to include a 'Copy to Clipboard' button on the API Key Request page that copies a well-formed XML fragment the user can paste to the requesting third-party app to be parsed?
If not immediately, place it in the hopper with the rest of the requests.
Thanks in advance, Elojs
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.07 15:47:00 -
[100]
Quote: Another thought, would it be possible to include a 'Copy to Clipboard' button on the API Key Request page that copies a well-formed XML fragment the user can paste to the requesting third-party app to be parsed?
The only thing they should have to copy for anyone else are the ID (KeyID) and Verification Code (vCode) and then you get to do the work via the API in your application. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
|
Elojs
Gallente Corp 42
|
Posted - 2011.08.07 18:36:00 -
[101]
Originally by: Dragonaire
Quote: Another thought, would it be possible to include a 'Copy to Clipboard' button on the API Key Request page that copies a well-formed XML fragment the user can paste to the requesting third-party app to be parsed?
The only thing they should have to copy for anyone else are the ID (KeyID) and Verification Code (vCode) and then you get to do the work via the API in your application.
I see that. However, I have less than complete faith in the abilities of the general public, and until now, that position has never disappointed me.
The idea here is the player presses a 'generate and copy to clipboard' button. The 3rd party app has a 'paste from clipboard' button. Click (copy), switch apps, click (paste). Parse.
The other consideration is the data portability provided by using XML to transport the data. Yapeal (nod to you) already parses XML on a routine basis, as does every other app making use of the API mechanism.
I'm attempting to set all this up on a website under a CMS that will be functional under the IGB as well as an external browser. The idea here is a website that leverages the API to its fullest extent, as well as supporting individuals, corporations, and alliances effectively. It's early days yet, but...
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.08.08 08:59:00 -
[102]
Originally by: Hel O'Ween The Market Order API doesn't seem to work for me on the test server. It now returns the same error that we currently see occasional on TQ for the wallet journal API:
Quote:
<eveapi version="2"> <currentTime>2011-08-03 16:17:09</currentTime> <error code="0">General Error: Scotty the docking manager heard you were talking **** about him behind his back and refuses to service your request.</error> <cachedUntil>2011-08-03 17:17:09</cachedUntil> </eveapi>
Does the MO API work for somebody? I'm still getting the above error.
For your convenience: https://apitest.eveonline.com/char/MarketOrders.xml.aspx?keyID=(yourKey)&vCode=(yourCode)
-- EVEWalletAware - an offline wallet manager |
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.08 09:59:00 -
[103]
Originally by: Hel O'Ween Does the MO API work for somebody? I'm still getting the above error.
Doesn't work for me either. Takes a while for the response to come back from the API only to find out that Scotty is being a jerk again.
EveHQ Character App |
|
CCP Stillman
|
Posted - 2011.08.08 10:52:00 -
[104]
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
|
|
|
CCP Stillman
|
Posted - 2011.08.08 10:52:00 -
[105]
Originally by: Kronus Heilgar
Originally by: Vessper
Originally by: CCP Stillman APIKeyInfo.xml.aspx contains a list of all characters you can query
Two possible ways this could be done:
1. Characters.xml.aspx shows all characters on the account, those that are accessible by the API key and also those that aren't. 2. APIKeyInfo.xml.aspx (or Characters.xml.aspx for that matter) adds another field indicating the number of characters created on the account. This would show if there are any additional characters but not disclose their IDs or names.
Personally, I'd prefer the first option but whatever is easier.
Agreed. That's what we'll do. My personal opinion is that the easiest and cleanest way would be to simply add this true/false "account-wide" field as part of the access mask.
|
|
|
CCP Stillman
|
Posted - 2011.08.08 11:07:00 -
[106]
Edited by: CCP Stillman on 08/08/2011 11:07:08
Originally by: Hel O'Ween
Originally by: Hel O'Ween The Market Order API doesn't seem to work for me on the test server. It now returns the same error that we currently see occasional on TQ for the wallet journal API:
Quote:
<eveapi version="2"> <currentTime>2011-08-03 16:17:09</currentTime> <error code="0">General Error: Scotty the docking manager heard you were talking **** about him behind his back and refuses to service your request.</error> <cachedUntil>2011-08-03 17:17:09</cachedUntil> </eveapi>
Does the MO API work for somebody? I'm still getting the above error.
For your convenience: https://apitest.eveonline.com/char/MarketOrders.xml.aspx?keyID=(yourKey)&vCode=(yourCode)
Scotty has been cranky for a while. Elerhino was on holiday last week, so he wasn't around to calm him down.
EDIT: Wow, I'm failing today.
|
|
EVEVERIFY Cashier
|
Posted - 2011.08.08 12:12:00 -
[107]
Originally by: CCP Stillman
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
Thank you, the only way you could make my day any better is by telling me your also doing an employment history api.
|
|
CCP Stillman
|
Posted - 2011.08.08 13:33:00 -
[108]
Edited by: CCP Stillman on 08/08/2011 13:33:21
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
Thank you, the only way you could make my day any better is by telling me your also doing an employment history api.
I don't wanna promise too much. But...
|
|
EVEVERIFY Cashier
|
Posted - 2011.08.08 17:41:00 -
[109]
Originally by: CCP Stillman Edited by: CCP Stillman on 08/08/2011 13:33:21
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
Thank you, the only way you could make my day any better is by telling me your also doing an employment history api.
I don't wanna promise too much. But...
|
Somatic Neuron
|
Posted - 2011.08.11 05:12:00 -
[110]
Anyone else getting Runtime Error on the server when trying to call even the simplest API call? (e.g. http://apitest.eveonline.com/api/calllist.xml.aspx)
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration> <system.web> <customErrors mode="Off"/> </system.web> </configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration> <system.web> <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/> </system.web> </configuration>
---------- |
|
|
CCP Stillman
|
Posted - 2011.08.11 10:02:00 -
[111]
Originally by: Somatic Neuron Anyone else getting Runtime Error on the server when trying to call even the simplest API call? (e.g. http://apitest.eveonline.com/api/calllist.xml.aspx)
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration> <system.web> <customErrors mode="Off"/> </system.web> </configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration> <system.web> <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/> </system.web> </configuration>
Sorry about that. We were deploying a new build for all of you to test on with a lot of requested features from you all. We need to fix some configuration, which will happen today, and it should work again.
|
|
|
CCP Stillman
|
Posted - 2011.08.11 17:34:00 -
[112]
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman
I don't wanna promise too much. But...
Here it is.
|
|
|
CCP Stillman
|
Posted - 2011.08.11 17:35:00 -
[113]
Originally by: CCP Stillman
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
The type attribute now returns either "Account", "Character" or "Corporation" depending on how it's made. I hope that fixes the issue.
|
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.11 21:32:00 -
[114]
You made my day with this:
Originally by: CCP Stillman
Originally by: CCP Stillman
Originally by: Johnathan Roark
I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.
My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.
Oh, I understand now.
Consider it done
The type attribute now returns either "Account", "Character" or "Corporation" depending on how it's made. I hope that fixes the issue.
And then, you added this on top of it.
Originally by: CCP Stillman
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman
I don't wanna promise too much. But...
Here it is.
I think I hurt my back attempting to do a backflip
POS-Tracker 3.0 Hosting |
Kronus Heilgar
Dark Orbit Media
|
Posted - 2011.08.12 03:28:00 -
[115]
Originally by: CCP Stillman
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman
I don't wanna promise too much. But...
Here it is.
OMG ur SO AMAZING THANK YOU THANK YOU THANK YOU I LOVE CAPS!!!!!!! ------------
EVE 3rd-Party Shutdown Party |
Somatic Neuron
|
Posted - 2011.08.12 03:32:00 -
[116]
Is there a good documentation site for the new way of doing things yet? ---------- |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.12 04:01:00 -
[117]
Just wanted to say thanks for the update to APKeyInfo so type now returns account, character, corporation that will make things much better.
The employment history on CharacterInfo is cool too even if Johnathan Roark ended up hurting his back over it -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Somatic Neuron
|
Posted - 2011.08.13 08:16:00 -
[118]
Originally by: CCP Stillman
The type attribute now returns either "Account", "Character" or "Corporation" depending on how it's made. I hope that fixes the issue.
Awesome...too bad we can't have an API of all accounts tied to one person ---------- |
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.14 00:53:00 -
[119]
Any update on getting that "install" link on the page?
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.14 03:32:00 -
[120]
Originally by: Dragonaire So I thought of something while looking at the XML for APIKeyInfo to make a new XSD schema for it. With all the changes from custom keys and added APIs etc shouldn't the version on <eveapi version="2"> be changed to '3'? It probably could have been changed before now but with as big of change as custom keys is I think it's important to reflect that in the version.
This is probably something that needs to be done, if for no other reason other then documentation sake.
POS-Tracker 3.0 Hosting |
|
Risingson
|
Posted - 2011.08.17 08:49:00 -
[121]
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to. // Eveeye.com |
Risingson
|
Posted - 2011.08.17 10:51:00 -
[122]
Edited by: Risingson on 17/08/2011 10:53:51
Process of creating predefined keys in matters of userfriendlyness: If i send a user to create a specific key i want him to do nothing much but eg. choosing the char and clicking "create". The way it's done atm will drive away some users or making them mess up ;)
to achieve that we would have to be able to additionally pass a name of key and expiry date. the representation should be reduced to minimum in case of predefinition.
could be as easy as this ... https://supporttest.eveonline.com/api/Key/CreatePredefined/16777216/?name=Eveeye.com%20Character%20Authentification should send the user to this imo
// Eveeye.com |
|
CCP Stillman
|
Posted - 2011.08.18 13:30:00 -
[123]
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
|
|
Desmont McCallock
|
Posted - 2011.08.18 14:00:00 -
[124]
Edited by: Desmont McCallock on 18/08/2011 14:07:39
Originally by: CCP Stillman
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
This is exactly the same issue I have reported a couple of weeks back. It's the 'lastKnownlocation' issue.
Btw, Stillman, do you want me to make a list of what still needs to be fixed?
|
Pomfineberer
|
Posted - 2011.08.18 18:01:00 -
[125]
Edited by: Pomfineberer on 18/08/2011 18:01:04 nm
|
Risingson
|
Posted - 2011.08.18 18:34:00 -
[126]
Originally by: CCP Stillman
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
reproduction steps: create a key for public char info only and use it to get your character info.
when i try:
keyID 428 got access mask 16777216 for CharacterInfo public only.
http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407
info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc // Eveeye.com |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.18 19:52:00 -
[127]
Originally by: Risingson
Originally by: CCP Stillman
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
reproduction steps: create a key for public char info only and use it to get your character info.
when i try:
keyID 428 got access mask 16777216 for CharacterInfo public only.
http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407
info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc
I think its suppose to return the same info as a limited api key would have?
POS-Tracker 3.0 Hosting |
Risingson
|
Posted - 2011.08.18 20:10:00 -
[128]
Edited by: Risingson on 18/08/2011 20:13:01
Originally by: Johnathan Roark
Originally by: Risingson
Originally by: CCP Stillman
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
reproduction steps: create a key for public char info only and use it to get your character info.
when i try:
keyID 428 got access mask 16777216 for CharacterInfo public only.
http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407
info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc
I think its suppose to return the same info as a limited api key would have?
that would not include accountbalance and lastlocation i think. but you are right naming it "public" is not a good choice.
edit added link :EVE_API_EVE_Character_Info // Eveeye.com |
Risingson
|
Posted - 2011.08.19 08:42:00 -
[129]
[[[offtopic: please give us an api for ongoing incursions]]] // Eveeye.com |
Desmont McCallock
|
Posted - 2011.08.22 14:34:00 -
[130]
Edited by: Desmont McCallock on 22/08/2011 14:37:52 We are almost one week away from CAK system deployment and IMO at this point we have a system that functions rather than a functional system.
Although many issues have been addressed, there are still some that persist and others that by solving them, would make our lives (as 3rd party app devs) much easier.
Let me explain.
Issues already spotted but still haven't been solved.
Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa. Solution: Reverse the results of eah call.
Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead. Solution: Set the date to one year from current date.
Issues that by solving them would make 3rd party app dev-lives easier.
Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).
Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.
Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
I would really appreciated, if I had a responce from CCP guys about the actions taken or will be taken for the above mentioned issues.
Discuss.
|
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.22 16:53:00 -
[131]
I'll agree with Desmont McCallock that the first couple points need fixed as I'm sure they will be but on the last couple I have a bit different view.
Quote: Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant. Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
I'd go the other way and merge Characters into APIKeyInfo and have in Yapeal already. Gets us to the same point and the API name makes more sense with the additional function it serves now.
Quote: Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary.
Not in the APIs though as they all work without it. I think if there weren't any 'Account' keys more people would see their way to better options but I'll give it a try in guiding you to how I've started viewing how to handle this. I'll try to put this as clearly as I can without making this post to long which I've been known to do What you are calling a accountID also known as userID by the old was limited and what you really need is a groupID for lack of something better to call it. What does a groupID do? It allows you to collect a bunch of keys for chars/corps so you can manage them. The group will be associated with a single RL person which for most web applications has a signin name etc but in non-web application doesn't usually have any since most desktop Eve applications are really single user. Now how does this help? Well you now can say group all of you manufacturing chars into a group, miners into group, all your PvP chars together in another, and your CEOs/Directors alts say into a different group and have settings that reflect their function and what you want to do with them without worrying about which 'account' they are on. There is even the option to have the same char be in more than one group if you use them for different things.
Notice how everything is about the chars just like the APIs keys are now but you can still manage them together as you need. You can do the same with corporations too. Say you have a couple of login accounts in Eve and have 6 chars. Lets say 2 char on the one account belong to corps in an alliance and maybe one on the other one is too. Lets say they are all CEOs or directors in the corps and you need to do some alliance business like do some kind of end of month report by using groups you can have a view on say the IndustryJobs that highlights just the ones dealing with the new Outpost you're building or a marketing group so you can do a report on how sales have been going in a region.
Hopefully this gives you some other ideas how NOT have an accountID in the API can be an advantage as now you can group things as you want to not as CCP would force you to do. You just associate the keys with the chars/corps as given in the APIs and then associate them how you or the users thinks makes sense. I'm out of time but hope this helps you see things in a different light and give you another direction to approach the problem. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Risingson
|
Posted - 2011.08.22 19:34:00 -
[132]
Originally by: Desmont McCallock The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it. // Eveeye.com |
Desmont McCallock
|
Posted - 2011.08.22 21:08:00 -
[133]
Originally by: Risingson
Originally by: Desmont McCallock The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.
At this point, the way CAK is configured, by looking into the APIKeyInfo call and according to the "type" value (aka "Account", "Character", "Corporation") of the key row, one is able to determine if the key provided is for the entire account (therefore exposes all characters in an account) or is restricting the access to a particular character (meaning there are more characters in the account and the user prefers to hide them).
My request has nothing to do with what you are referring rather is a request to provide us with additional info to bound multiple API keys to an account.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.22 21:40:00 -
[134]
Originally by: Desmont McCallock Edited by: Desmont McCallock on 22/08/2011 14:37:52 We are almost one week away from CAK system deployment and IMO at this point we have a system that functions rather than a functional system.
Although many issues have been addressed, there are still some that persist and others that by solving them, would make our lives (as 3rd party app devs) much easier.
Let me explain.
Issues already spotted but still haven't been solved.
Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa. Solution: Reverse the results of eah call.
I also think "public" is a poor choice of words. Also, any chance of either moving it to char/ or at least making an alias in char/. eve/ is more for global stats.
Originally by: Desmont McCallock
Issues that by solving them would make 3rd party app dev-lives easier.
Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).
Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
Account keys that can see all characters absolutely need this in the APIKeyInfo call or Characters, I prefer APIKeyInfo. I would also like to see it in character specific calls, especially if AccountStatus is enabled. Corporation keys its not needed.
Originally by: Desmont McCallock
Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.
Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
I would rather see it the other way, APIKeyInfo stays. That being said, I wouldn't completely remove Characters on Aug 30, I would imply that its slated to be removed and remove it when old style keys can no longer be used or generated. Maybe sometime in December?
Originally by: Desmont McCallock
Originally by: Risingson
Originally by: Desmont McCallock The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.
At this point, the way CAK is configured, by looking into the APIKeyInfo call and according to the "type" value (aka "Account", "Character", "Corporation") of the key row, one is able to determine if the key provided is for the entire account (therefore exposes all characters in an account) or is restricting the access to a particular character (meaning there are more characters in the account and the user prefers to hide them).
My request has nothing to do with what you are referring rather is a request to provide us with additional info to bound multiple API keys to an account.
It would only expose your alts if your telling the same site multiple characters, and lets be honest, it doesn't take that much to figure out that two characters that have the same IP and the same user-agent are likely the same owner. That being said, at the very least, an accountID (or userID) should be returned for keys that have a type of "account". Personally, I see no issue returning it for "character" as well. I guess the biggest thing that a lot of sites will have not having it is deciding if a character has changed hands.
EVEVERIFY Recruitment API Verifier |
Desmont McCallock
|
Posted - 2011.08.23 08:46:00 -
[135]
I merely suggested to keep the Characters call as this is currently used and you know how people dislike changes. I have no problem keeping both or either.
On another note, I gave Dragonaire's suggestion a thought and I came also to the conclusion that the mutli-key association of same account api keys can be made based on character id rather than account id. I'll keep you informed on how this progresses.
|
|
CCP Stillman
|
Posted - 2011.08.23 10:27:00 -
[136]
Originally by: Risingson Edited by: Risingson on 19/08/2011 08:50:27
Originally by: CCP Stillman
Originally by: Risingson Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.
What info exactly? I can't reproduce that :(
reproduction steps: create a key for public char info only and use it to get your character info.
when i try:
keyID 428 got access mask 16777216 for CharacterInfo public only.
http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407
info it should not contain but does are accountBalance , lastKnownLocation
I see what's going on. Thanks!
|
|
|
CCP Stillman
|
Posted - 2011.08.23 10:31:00 -
[137]
Originally by: Desmont McCallock
Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa. Solution: Reverse the results of eah call.
No. The issue in question is not as simple as that. And it will be fixed very soon.
Originally by: Desmont McCallock
Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead. Solution: Set the date to one year from current date.
Fix will be deployed with the next deployment, don't worry
Originally by: Desmont McCallock
Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).
Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
No. This is not an option. The userID won't be in the accountstatus call for much longer.
Originally by: Desmont McCallock
Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.
Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
We don't deprecate calls, especially not this late in development. I don't see how duplicate information can be a problem.
|
|
|
CCP Stillman
|
Posted - 2011.08.23 10:32:00 -
[138]
Originally by: Risingson
Originally by: Desmont McCallock The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.
We are moving completely away from userIDs. They are simply a leftover thing from the original implementation. There should not be any userIDs exposed through the API anymore, ever.
|
|
Desmont McCallock
|
Posted - 2011.08.23 11:16:00 -
[139]
First I would like to thank you Stillman for replying and ease my (our) concerns. Some times your replies don't come as fast as we want. But any reply is better than no reply, right?
Originally by: CCP Stillman
Originally by: Desmont McCallock
Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa. Solution: Reverse the results of eah call.
No. The issue in question is not as simple as that. And it will be fixed very soon.
OK, do what you have to do. As long as it get fixed before deployment.
Originally by: CCP Stillman
Originally by: Desmont McCallock
Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead. Solution: Set the date to one year from current date.
Fix will be deployed with the next deployment, don't worry
I'm happy.
Originally by: CCP Stillman
Originally by: Desmont McCallock
Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).
Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.
No. This is not an option. The userID won't be in the accountstatus call for much longer.
Another one bites the dust...
Originally by: CCP Stillman
Originally by: Desmont McCallock
Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.
Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
We don't deprecate calls, especially not this late in development. I don't see how duplicate information can be a problem.
It was merely a suggestion based on DRY principal. No, duplicate info are no problem.
|
|
CCP Stillman
|
Posted - 2011.08.24 12:04:00 -
[140]
New build has been deployed with all fixes for stuff mentioned in here |
|
|
Desmont McCallock
|
Posted - 2011.08.24 17:01:00 -
[141]
Edited by: Desmont McCallock on 24/08/2011 17:10:04 I can still see the accountBalance and the lastKnownLocation elements in the "Public" CharacterInfo call. There is though a possibility that API has to get its cache flushed (I already did it with my browser, the data are still there, even tried with all 3 major browsers) as the lastKnownLocation I'm in right now in SiSi isn't the same as the data returned by the API.
@CCP Stillman Edit: I just figured out were the error is with the CharacterInfo calls. The error lies with the web page as it has the "Public" CharacterInfo call listed in the "Private Information" group and vice versa. The accessMask of both calls are correct. So switching places of the calls on the web page will fix future misunderstandings.
@Johnathan Roark Notice that the userID has been deprecated from the accountStatus call.
|
Mella Elcus
|
Posted - 2011.08.24 20:38:00 -
[142]
Originally by: CCP Stillman No. This is not an option. The userID won't be in the accountstatus call for much longer.
Then is the cached until on accountstatus tied to the key or the account?
Say you have two keys from the same account both with accountstatus. If the cache timer is tied to the account then there is no way to prevent "violating" the cache timer and getting your IP temporary banned.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.25 04:43:00 -
[143]
I've been using the default 5 minute cachedUntil with 3 overlapping keys with 2-3 chars per account key and not ran into problems in testing so I don't foresee it being to much of a problem being banned.If you are worried about it you can try using a longer cache time as the info shouldn't be changing that often really. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.26 20:17:00 -
[144]
I've been getting things together for the new API and I've found some oddness with some corp related data and want some clarification as to whether I understand this correctly.
Basically, any corp orders or contracts are currently listed under the character which made the order/contract. I would have thought that such items would be listed under the corp APIs rather than the characters. The industry jobs API appears to work correctly in this regard, with any jobs started from corporate hangars being listed in the corp APIs and not the character APIs.
So, I guess what I'm asking is if the orders and contracts APIs are currently broke or is there some design aspect I'm not understanding?
EveHQ Character App |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.27 04:57:00 -
[145]
It's just been brought to my attention something that is very puzzling and got to be an error. We have some APIs with more than one bit in the accessMask and all the APIs having at least one bit with the exception of APIKeyInfo and accountCharacters where it makes sense not to have one.
Now what is puzzling is how the contract APIs ending up with only one when even dependent APIs for Starbases (POS), Mail, etc all get their own? This just doesn't make any sense at all. The total lack of consistence here I can't understand really. Now I'll have to say for my part why I didn't notice it before I don't know and I'll take some of the blame for not noticing sooner and saying something about it but how did this get missed by everyone at CCP and all the third party developers? I don't know about anyone else but with how Yapeal works this is going to cause a lot of problems and really is an error as far as I'm concerned and needs to be fixed even if it might delay contract API to do so and not have the contract APIs available with patch launch next Tuesday.
I know Johnathan Roark post something about this in the contract API thread as well. He was the one that brought it to my attention with a question about how it would work in Yapeal. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
MJ Maverick
IronPig Sev3rance
|
Posted - 2011.08.27 19:38:00 -
[146]
So is this an added extra or replacing the Limited API completely?
If it's replacing it completely I don't see how EVEOTS can survive, thanks. The system needs to have permission to check alliances/corporations and all characters on the account. Along with tickers, corp IDs, alliance IDs etc etc...
So I'm now going to have to ask the user to create a specific API for me. Politely asking "please can you not hide your red alt character Mr Spy". This is all going to add up to my simple registration steps becoming a bastion of complicated and confusing errors for the users.
As the only way to check if a resource isn't there (hidden) is to generate an error and many can be generated one after another and that's just for one person registering then any server using EVEOTS will be blocked from talking to the API server within just a couple of registrations... The whole system comes to a halt and the system to get your guys registered on comms comes to a grinding halt.
So in short Stillman. This idea seems like a great option but please, please, I implore you; do not remove the Limited API. People won't be willing to hand over a FULL API so there is no substitute for keeping the Limited API that can't be messed with as an option.
- Mav
------------------ CCP are not perfect. :) [EVEOTS] Eve Online Teamspeak 3 API Registration
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.27 20:06:00 -
[147]
Originally by: MJ Maverick So is this an added extra or replacing the Limited API completely?
If it's replacing it completely I don't see how EVEOTS can survive, thanks. The system needs to have permission to check alliances/corporations and all characters on the account. Along with tickers, corp IDs, alliance IDs etc etc...
So I'm now going to have to ask the user to create a specific API for me. Politely asking "please can you not hide your red alt character Mr Spy". This is all going to add up to my simple registration steps becoming a bastion of complicated and confusing errors for the users.
As the only way to check if a resource isn't there (hidden) is to generate an error and many can be generated one after another and that's just for one person registering then any server using EVEOTS will be blocked from talking to the API server within just a couple of registrations... The whole system comes to a halt and the system to get your guys registered on comms comes to a grinding halt.
So in short Stillman. This idea seems like a great option but please, please, I implore you; do not remove the Limited API. People won't be willing to hand over a FULL API so there is no substitute for keeping the Limited API that can't be messed with as an option.
- Mav
This is replacing both limited and full, what you'll have to do is check if the type is "account" in APIKeyInfo. If for some reason you need access to any of the other calls, you'll also need to check if it has the correct access mask, but I can't see why it would. This change is actually great for registration because it exposes less so players will be more likely to hand over keys.
EVEVERIFY Recruitment API Verifier |
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.28 00:28:00 -
[148]
I know you guys are busy but can you please add that install link. You will greatly simply mobile entry. I should even go as far as say that this is a must before you deploy this API since you remove the "UserID:" and "API Key:" text from the page. Users can no longer just select a large block of text and return to my app. PLEASE just add the link!
|
Zifrian
Deep Space Innovations
|
Posted - 2011.08.28 13:23:00 -
[149]
Is there a way to see Corp Assets from a character key? I see that the keys are separated into corporation and character but in the old API system, with a full key you could see corporation assets when using a character that was in the corp.
I can totally see how you want to keep asset information restricted to directors, but the reason this is useful is for industry programs that allow scanning of corp blueprints for use. Many industrialist characters make their own corps and share bps with multiple alts with the use of the corp. Industrial corps do this as well for multiple members and if a user wants to use a program that calculates data on manufacturing from a corp blueprint, they won't have access to this now. Even the director of the corp will have to enter a separate key to scan for corporation blueprints. I guess the director could share this key for use by members, but that is not ideal for many reasons. Plus, it creates a bit of programming work to separate.
Is there something I'm missing here that gives this functionality or is there a workaround to get this functionality? SOL? --- Maximize your Industry Potential! Download EVE Isk per Hour Here! |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.28 16:57:00 -
[150]
Originally by: Zifrian Is there a way to see Corp Assets from a character key? I see that the keys are separated into corporation and character but in the old API system, with a full key you could see corporation assets when using a character that was in the corp.
I can totally see how you want to keep asset information restricted to directors, but the reason this is useful is for industry programs that allow scanning of corp blueprints for use. Many industrialist characters make their own corps and share bps with multiple alts with the use of the corp. Industrial corps do this as well for multiple members and if a user wants to use a program that calculates data on manufacturing from a corp blueprint, they won't have access to this now. Even the director of the corp will have to enter a separate key to scan for corporation blueprints. I guess the director could share this key for use by members, but that is not ideal for many reasons. Plus, it creates a bit of programming work to separate.
Is there something I'm missing here that gives this functionality or is there a workaround to get this functionality? SOL?
The program will have to update to compensate, which they needed to do anyway for other parts of this system. Only director or CEO keys could see corp assets before so I do not see this a big deal.
EVEVERIFY Recruitment API Verifier |
|
Zifrian
Deep Space Innovations
|
Posted - 2011.08.28 20:21:00 -
[151]
Originally by: Johnathan Roark The program will have to update to compensate, which they needed to do anyway for other parts of this system. Only director or CEO keys could see corp assets before so I do not see this a big deal.
Ahh, I did not realize that. That is useful to know. However, if a member is not a director but they can see/use corp assets, how will they be able to access them now?
--- Maximize your Industry Potential! Download EVE Isk per Hour Here! |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.29 02:13:00 -
[152]
They will have to get a new key from a director or the CEO no other way now. The good thing is the key only has to give them the access they need now and they only get access to corp info and not also all the personal info of whomever gives them the key. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Artem Valiant
|
Posted - 2011.08.29 13:03:00 -
[153]
Unable to login at https://supporttest.eveonline.com/API/ with Safari 4.0.4(6531.21.10) under Mac. After sending login and password, browser returns to the login page (https://supporttest.eveonline.com/Pages/Login.aspx?ReturnUrl=%2fAPI%2f) Under Firefox all ok.
Thanks, Artem
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.29 13:45:00 -
[154]
Originally by: Marcel Devereux I know you guys are busy but can you please add that install link. You will greatly simply mobile entry. I should even go as far as say that this is a must before you deploy this API since you remove the "UserID:" and "API Key:" text from the page. Users can no longer just select a large block of text and return to my app. PLEASE just add the link!
We have actually looked into this but we need a bit more information as to how exactly to implement this. So you need a link for every key in the list, each link can go anywhere, it just needs to have the keyID and vCode parameters, right? We only want this to show up on mobile devices so we're wondering if it would suffice to add a parameter on the overview page or if we'd need to have a mobile device detection.
CCP Elerhino CCP Software - API
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.29 13:50:00 -
[155]
Originally by: Vessper I've been getting things together for the new API and I've found some oddness with some corp related data and want some clarification as to whether I understand this correctly.
Basically, any corp orders or contracts are currently listed under the character which made the order/contract. I would have thought that such items would be listed under the corp APIs rather than the characters. The industry jobs API appears to work correctly in this regard, with any jobs started from corporate hangars being listed in the corp APIs and not the character APIs.
So, I guess what I'm asking is if the orders and contracts APIs are currently broke or is there some design aspect I'm not understanding?
Characters can see all contracts they've issued, corporations can see the ones that were issued for corporations. So the lists currently overlap, corporation contracts should show up on both lists.
CCP Elerhino CCP Software - API
|
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.29 14:32:00 -
[156]
Originally by: CCP Elerhino
Originally by: Marcel Devereux I know you guys are busy but can you please add that install link. You will greatly simply mobile entry. I should even go as far as say that this is a must before you deploy this API since you remove the "UserID:" and "API Key:" text from the page. Users can no longer just select a large block of text and return to my app. PLEASE just add the link!
We have actually looked into this but we need a bit more information as to how exactly to implement this. So you need a link for every key in the list, each link can go anywhere, it just needs to have the keyID and vCode parameters, right? We only want this to show up on mobile devices so we're wondering if it would suffice to add a parameter on the overview page or if we'd need to have a mobile device detection.
For each key a new link in the Actions section. That is for each key you would have [Update][Delete][Install]. The link can be anything as long as it has ?keyID=XXX&vCode=YYY appended on it. If you don't want the link to go anywhere you can create a custom scheme (i.e. eve://api.eveonline.com/?keyID=XXX&vCode=YYY). When clicked on the desktop or mobile browser this will do nothing if there is no url handler installed. If there is url handler installed, whether it is the desktop or mobile device, (google 'installing url handlers' on how to do this on windows) it will prompt the user asking them to launch the application. The application can the parse the query parameters and install the key with just one click from the user!
I do not see the need to limit this to mobile devices. First is that mobile detection won't always work because of how tablet browsers present themselves. Secondly EVEMon/EVEHQ/EFT could use this method as well.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.29 14:38:00 -
[157]
Originally by: CCP Elerhino
Originally by: Vessper I've been getting things together for the new API and I've found some oddness with some corp related data and want some clarification as to whether I understand this correctly.
Basically, any corp orders or contracts are currently listed under the character which made the order/contract. I would have thought that such items would be listed under the corp APIs rather than the characters. The industry jobs API appears to work correctly in this regard, with any jobs started from corporate hangars being listed in the corp APIs and not the character APIs.
So, I guess what I'm asking is if the orders and contracts APIs are currently broke or is there some design aspect I'm not understanding?
Characters can see all contracts they've issued, corporations can see the ones that were issued for corporations. So the lists currently overlap, corporation contracts should show up on both lists.
In that case, it's not working. Looking at my character contracts, I have one that states:
<row contractID="44541527" issuerID="440717473" issuerCorpID="239093838" assigneeID="0" acceptorID="0" startStationID="60002770" endStationID="60002770" type="ItemExchange" status="Outstanding" title="Corp Shuttle Exchange" forCorp="1" availability="Public" dateIssued="2011-08-26 18:38:52" dateExpired="2011-09-09 18:38:52" dateAccepted="" numDays="0" dateCompleted="" price="1234567.00" reward="0.00" collateral="0.00" buyout="0.00" volume="2500" />
If you look at the corp contracts, the XML returns no rows and the corp/ContractItems gives an invalid contractID.
EveHQ Character App |
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.29 14:40:00 -
[158]
This page has a example of the link: http://aura.aideronrobotics.com/test.html
When clicked it does nothing. I can register to handle that scheme (eve) and that host (api.eveonline.com) in Aura. I will get launched with the full URL and I can parse out the parameters.
|
Risingson
|
Posted - 2011.08.29 21:29:00 -
[159]
Originally by: Risingson Process of creating predefined keys in matters of userfriendlyness: If i send a user to create a specific key i want him to do nothing much but eg. choosing the char and clicking "create". The way it's done atm will drive away some users or making them mess up. to achieve that we would have to be able to additionally pass a name of key and expiry date. the representation should be reduced to minimum in case of predefinition. could be as easy as this ... https://supporttest.eveonline.com/api/Key/CreatePredefined/16777216/?name=Eveeye.com%20Character%20Authentification should send the user to this imo
I tested with a few users. many asked "where is my keyID?". thats because the "Create API key" page shows the verification code and people think thats the key already... most people cannot see the "submit" button on bottom right due to their screen size. please move the submit button below the expiry section.
While you are at that section set the expiry date to something that won't make the key expire at creation since all testers generated a key that instantly expired.
proper userfriendly predefined landing page
please take off your coder monocles
// Eveeye.com |
Bushwacker Bob
|
Posted - 2011.08.30 12:23:00 -
[160]
Quick question I just thought up of, We're thinking of forcing users to regenerate their keys after Thursday's downtime, If a user creates a new style key will the old style key stop working?
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 13:19:00 -
[161]
Originally by: Vessper In that case, it's not working. Looking at my character contracts, I have one that states:
<row contractID="44541527" issuerID="440717473" issuerCorpID="239093838" assigneeID="0" acceptorID="0" startStationID="60002770" endStationID="60002770" type="ItemExchange" status="Outstanding" title="Corp Shuttle Exchange" forCorp="1" availability="Public" dateIssued="2011-08-26 18:38:52" dateExpired="2011-09-09 18:38:52" dateAccepted="" numDays="0" dateCompleted="" price="1234567.00" reward="0.00" collateral="0.00" buyout="0.00" volume="2500" />
If you look at the corp contracts, the XML returns no rows and the corp/ContractItems gives an invalid contractID.
This is most likely a defect where Public (availability) contracts were displayed for characters but not for corporations. The fix is coming.
CCP Elerhino CCP Software - API
|
|
Desmont McCallock
|
Posted - 2011.08.30 14:50:00 -
[162]
@CCP Elerhino & CCP Stillman
CharacterInfo call (accesMask="16777216") is still placed in "Public Information" (groupID="4") although this call exposes private info.
CharacterInfo call (accesMask="8388608") is still placed in "Private Information" (groupID="3") although this call exposes public info.
Please confirm that you are aware and have a fix planned. Would hate to see this bug go live.
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 17:50:00 -
[163]
Originally by: Bushwacker Bob Quick question I just thought up of, We're thinking of forcing users to regenerate their keys after Thursday's downtime, If a user creates a new style key will the old style key stop working?
No, we'll allow the old keys for a period of time. We haven't decided for how long but we're thinking something like 4-8 weeks.
CCP Elerhino CCP Software - API
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 17:53:00 -
[164]
Originally by: Desmont McCallock Edited by: Desmont McCallock on 30/08/2011 16:33:09 @CCP Elerhino & CCP Stillman
CharacterInfo call (accessMask="16777216") is still placed in "Public Information" (groupID="4") although this call exposes private info.
CharacterInfo call (accessMask="8388608") is still placed in "Private Information" (groupID="3") although this call exposes public info.
Please confirm that you are aware and have a fix planned. Would hate to see this bug go live.
We have fixed this, SISI wasn't updated before by mistake but should be shortly. Thanks for the heads up.
CCP Elerhino CCP Software - API
|
|
Frozen Guardian
Registered Amateur Mathematicians
|
Posted - 2011.08.30 21:29:00 -
[165]
I have two issues with the disabling of old keys and new players not getting new keys(if I understand that's what is going to happen) and this new system in general. We have to get our apps updated to use the new keys. However old apps or older versions that people stay on will no longer work.
People love their apps for EVE and turning off old keys without a huge warning about it on the API page is bad news. Right now you should have a huge red bold text on the EVE API Key Management page stating that these keys will no longer work in the next few months. Then a more detail explanation as to why and what to do(like look for new versions of the apps you use). How to make sure their app is compatible and etc. Personally I can't see this working out nicely for EVE Players unless the old keys are kept on for a year while people start searching for new apps and see if people update old apps if they are open sourced. Plus there is so much in-house built apps to do certain functions those developers may not even know this is happening. Hell they maybe in another corp/alliance now or not even play.
This blog here: http://www.eveonline.com/devblog.asp?a=blog&nbid=2319 makes sense to me as a developer. As a normal player(especially a new player) this would fly over my head. For various things in EVE I've had to show people how to get to their API page and make them understand what it is. I can't expect these players to understand that an API change is coming up and they have to generate a new key, some old apps may not work, and what to select.
On sort of that topic the Create API key needs presets(limited API) or additional information. The question mark towards brings up API information on what is given which isn't detailed enough. APIs specific to information that used to be under the Full Access API like the wallet should have a warning on them and state things like the application or players with this key can see everything you do in terms of buying/selling/etc. Them seeing the XML results is pointless. Plus some may just not understand it and basically start using Full API data for everything. It's easier to click All in each section than it is to understand what I'm actually selecting. It's just opening up for abuse in a sense from people tricking others into getting what used to be the Full Access API key.
-FG
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.01 04:46:00 -
[166]
Quote: On sort of that topic the Create API key needs presets(limited API) or additional information. The question mark towards brings up API information on what is given which isn't detailed enough. APIs specific to information that used to be under the Full Access API like the wallet should have a warning on them and state things like the application or players with this key can see everything you do in terms of buying/selling/etc. Them seeing the XML results is pointless. Plus some may just not understand it and basically start using Full API data for everything. It's easier to click All in each section than it is to understand what I'm actually selecting. It's just opening up for abuse in a sense from people tricking others into getting what used to be the Full Access API key.
Just had to comment on this. Your right but this is kind of like with warning before entering low sec most people are just going to ignore or not understand it and jump through anyway and until they've had their ship blown up they don't understand most of them. I bet if you did a poll most Eve players have to go through that before they truly understand what's going on. I did it myself I know and I had a couple friends that had been playing Eve for a while warning me as well not to go into low sec or I'd end up losing my ship at least For most people the only way they can learn is by making the mistake themselves then they pay attention when only a rare few can learn from seeing or hearing about others mistakes. Anyway that's my 0.02 ISK on it -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Nabrek Tarell
|
Posted - 2011.09.02 07:40:00 -
[167]
Edited by: Nabrek Tarell on 02/09/2011 07:45:44 Never mind nothing to see here but failure to read :) |
TornSoul
BIG Gentlemen's Agreement
|
Posted - 2011.09.02 10:40:00 -
[168]
Edited by: TornSoul on 02/09/2011 10:46:13
These new keys are an important step forward towards improved granularity and better control of our data.
That said, it's bolted on to the (old) existing API pages.
One of the primary uses of giving out your API key is for corp/alliance forum and communication - For authentication purposes.
Presently the current selection of API pages *still* give out more info than what is needed for these purposes.
So.. Could we please have a new API page tailored towards this need.
As a minimum that particular page would need the following info (and ONLY) : Authentication page -Character name and ID -Corp name and ID (name not really needed) -Role/title mask (to see if the char should have elevated forum/voice access, if it's a dir/CEO or the like) -Active - Indicating if the account is active (paid for) or not (this one could be debated)
And that's it (at the top of my head anyhow)
------
Note that there is no clone/wallet balance/skill/etc/etc info. That info simply isn't needed for authentication purposes - and I for one don't care to expose it if it isn't needed (which is why BLEEP exists)
Note that the above would be one single API call. Today to get all that info you'd need several API calls, not to mention the amount of data returned can be huge compared to the above suggestion (I'm thinking skills/certificates here - info that is no business of a forum authentication program anyhow)
------
One other thing most authentication programs likes to do, is to check which other chars you got on that account (as a soft check for spies etc). That today requires a call to the account page. One *could* argue to include that info in the above suggested authentication page. Arguments both for and against this. As such I think it better to exclude it, to at least have that minimum "info-surface" page.
Dear CCP - Please create an "Authentication" API page.
BIG Lottery |
Raw Matters
Minmatar
|
Posted - 2011.09.02 12:29:00 -
[169]
Just started working with the new Eve API and the first thing I had to notice was... a complete lack of documentation. The page www.eveonline.com/api/doc/ is actually blank, the wiki.eveonline.com/en/wiki/EVE_API_Functions site is well hidden and while well documented does not refer to the new API key system. I actually had to search the forum and blog to find the new vCode parameter and how to use it. Please fix that, otherwise people with good ideas might get stuck on step one.
After taking that hurdle I was finally able to get some results. My impression so far is that the Eve API is very nice in general but lacks or is flawed in some details.
- No cross-domain requests are supported which makes it impossible to create browser based tools. Please add a JSONP parameter (like callback="...") that returns the response formatted according to the JSONP definition. This would make a lot of JavaScript developers happy.
- Only XML is requestable, which is ok but JSON would be a really nice to have.
- The results are very talkative, many parts of the content aren't really required or could be shortened, they look very much like a plain data dump. Lets take this example result:
Quote: <eveapi version="2"> <currentTime> 2011-09-02 11:22:18 </currentTime> <result> <rowset name="characters" key="characterID" columns="name,characterID"> <row name="Raw Matters" characterID="1753964596"/> </rowset> </result> <cachedUntil> 2011-10-02 11:22:18 </cachedUntil> </eveapi>
It does contain all required information, but actually I only wanted the row elements. A much more compact while equally expressive result could look like this:
Quote: <eveapi version="2"> <results time="2011-09-02 11:22:18" cachedUntil="2011-10-02 11:22:18"> <character name="Raw Matters" id="1753964596"/> </results> </eveapi>
A similar example would be the market order list: I am probably only interested in recent market orders or those of a specific state, but there are no parameters to limit/filter the response. This does not only cause a lot of unnecessary traffic to be send over the line, but requires the client to parse a lot of noise as well just to get to the interesting part.
- In addition to this as a best practice it has been established to put the API version number into the URL instead of the response. This serves two purposes: for once on each version update all caches are automatically clean (as the URL is different) and for second any client can continue to send calls to a version this client knows it is compatible to until this client has been updated to the new version (aka you don't break stuff). Example: https://api.eveonline.com/v2/eve/CharacterID.xml.aspx?names=Raw%20Matters
- The response contains no caching header information although the caching time is very well defined by CCP. Something like "max-age: 3600" or "Expires: ..." would be great and would take some load of your servers as well.
- There is no XML schema defined for the response and there is none linked in the response. While this is not necessary for a response to be parsed, it would help you and testers a lot to check whether or not the response is actually grammatically correct. In addition many XML parsers (like Java) offer an automated parsing code generation if such XSD is defined.
- While the new API keys are from a developer perspective very nice, they are a hassle to use for users that do not have a technical background. I suggest to create template permission settings to help these users like "Skill & Learning", "Market data", "Corporation information".
|
Zifrian
Deep Space Innovations
|
Posted - 2011.09.04 13:40:00 -
[170]
Possible Bug
When querying the Account API (/account/APIKeyInfo.xml.aspx) with a Character ID, the result is all characters on the account.
I'm not sure if this is intended, since it's an Account query and not a character, but that makes me wonder why you even allow for a character ID to be sent with the account if you aren't going to use it.
Thanks --- Maximize your Industry Potential! Download EVE Isk per Hour Here! |
|
Sua Vis
|
Posted - 2011.09.04 14:53:00 -
[171]
Don't know if it has already been said: It would be great, to request the trained skills within the CharacterSheet, without having to be served with additional personal data like account balance.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.04 17:03:00 -
[172]
Quote: I'm not sure if this is intended, since it's an Account query and not a character, but that makes me wonder why you even allow for a character ID to be sent with the account if you aren't going to use it.
Actually all the APIs seem to ignore any parameters they don't understand which is what you are probably noticing. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Xander Hunt
Minmatar Dead Rats Tell No Tales
|
Posted - 2011.09.05 04:16:00 -
[173]
Some sort of call back *PLEASE* for that INSTALL link.
I'm loving the eve:// for mobile phones, but for desktop or web apps, the install should be able to "link back" to whatever made the call. Aura (For Android) works BRILLIANTLY with this.
For a web interface, it'd be a snap. My web application would provide POST data to the API server with a URL to which is should send data back to when clicking INSTALL. When the user clicks the INSTALL, the install HREF points http://myserver.com/path/installkey?keyID=4325&vCode=JkujoankjnAASL879KN where red is what we provide in the POST and yellow is what you return to us.
I'm scratching my head as to how this could be streamlined for desktop apps, and it may just boil down to a user having to copy/paste. But a desktop app is a different beast compared to a web interface, in that the web interfaces SHOULD be able to talk with each other more seamlessly.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.09.05 06:11:00 -
[174]
Edited by: Johnathan Roark on 05/09/2011 06:13:02
Originally by: Xander Hunt Some sort of call back *PLEASE* for that INSTALL link.
I'm loving the eve:// for mobile phones, but for desktop or web apps, the install should be able to "link back" to whatever made the call. Aura (For Android) works BRILLIANTLY with this.
For a web interface, it'd be a snap. My web application would provide POST data to the API server with a URL to which is should send data back to when clicking INSTALL. When the user clicks the INSTALL, the install HREF points http://myserver.com/path/installkey?keyID=4325&vCode=JkujoankjnAASL879KN where red is what we provide in the POST and yellow is what you return to us.
I'm scratching my head as to how this could be streamlined for desktop apps, and it may just boil down to a user having to copy/paste. But a desktop app is a different beast compared to a web interface, in that the web interfaces SHOULD be able to talk with each other more seamlessly.
Desktop apps can register the eve:// handler, only issue is web apps, they have no way to do that. Problem I see is several apps competing for the url handler. The call back for web apps would be great though.
EVEVERIFY Recruitment API Verifier |
Creeping Tiger
Caldari Interstellar Brotherhood of Gravediggers The 0rphanage
|
Posted - 2011.09.06 08:11:00 -
[175]
I am still unable to access the new API information on both of my accounts.
I enter the username and password then enter the name of a character on that account but it just returns me to the login page again.
Any suggestions?
CT
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.09.06 08:44:00 -
[176]
Edited by: Hel O''Ween on 06/09/2011 08:47:17 The "No Expiry" checkbox doesn't seem to work (on the test server).
I have a key set to not expire (checkbox checked). The greyed out date for that key is today (2012/09/06). When querying the API with that key, the following error is returned from the API:
Quote:
EVE API Error: 222, Key has expired. Contact key owner for access renewal.
To me it seems that the (disabled) date is checked regardless of the setting of the "No expiry" checkbox.
[Added] Erhm ... just recognised the date not set to today, but to today next year. Doesn't change the fact that the API error doesn't make sense. -- EVEWalletAware - an offline wallet manager |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.06 14:35:00 -
[177]
Make sure you aren't trying to use any test server keys on main server or the other way around as I believe you get that error in both cases. |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.09.06 15:29:00 -
[178]
Originally by: Dragonaire Make sure you aren't trying to use any test server keys on main server or the other way around as I believe you get that error in both cases.
I plead guilty as charged.
(Where's that :doh: or :rtfm: smiley if you need it?) -- EVEWalletAware - an offline wallet manager |
|
|
|
Pages: 1 2 3 4 5 6 :: [one page] |