|
Author |
Thread Statistics | Show CCP posts - 37 post(s) |
Desmont McCallock
|
Posted - 2011.07.21 19:16:00 -
[1]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 07:10:00 -
[2]
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 -
[3]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 14:14:00 -
[4]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 14:26:00 -
[5]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 14:44:00 -
[6]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 15:01:00 -
[7]
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. :)
|
Desmont McCallock
|
Posted - 2011.07.22 15:37:00 -
[8]
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.
|
Desmont McCallock
|
Posted - 2011.07.22 18:03:00 -
[9]
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.
|
Desmont McCallock
|
Posted - 2011.07.24 08:37:00 -
[10]
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.
|
|
Desmont McCallock
|
Posted - 2011.07.29 08:35:00 -
[11]
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?
|
Desmont McCallock
|
Posted - 2011.07.29 17:23:00 -
[12]
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 -
[13]
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.
|
Desmont McCallock
|
Posted - 2011.07.30 06:32:00 -
[14]
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?
|
Desmont McCallock
|
Posted - 2011.08.02 13:38:00 -
[15]
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?
|
Desmont McCallock
|
Posted - 2011.08.03 13:25:00 -
[16]
@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.
|
Desmont McCallock
|
Posted - 2011.08.03 21:32:00 -
[17]
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 -
[18]
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.
|
Desmont McCallock
|
Posted - 2011.08.06 12:51:00 -
[19]
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.
|
Desmont McCallock
|
Posted - 2011.08.18 14:00:00 -
[20]
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?
|
|
Desmont McCallock
|
Posted - 2011.08.22 14:34:00 -
[21]
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.
|
Desmont McCallock
|
Posted - 2011.08.22 21:08:00 -
[22]
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.
|
Desmont McCallock
|
Posted - 2011.08.23 08:46:00 -
[23]
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.
|
Desmont McCallock
|
Posted - 2011.08.23 11:16:00 -
[24]
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.
|
Desmont McCallock
|
Posted - 2011.08.24 17:01:00 -
[25]
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.
|
Desmont McCallock
|
Posted - 2011.08.30 14:50:00 -
[26]
@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.
|
|
|
|