|
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
|
|
|
CCP Stillman
|
Posted - 2011.07.21 13:20:00 -
[2]
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 :)
|
|
|
CCP Stillman
|
Posted - 2011.07.22 13:23:00 -
[3]
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 -
[4]
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 -
[5]
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 -
[6]
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 -
[7]
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 :(
|
|
|
CCP Stillman
|
Posted - 2011.07.22 14:30:00 -
[8]
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 -
[9]
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!
|
|
|
CCP Stillman
|
Posted - 2011.07.22 14:50:00 -
[10]
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 -
[11]
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
|
|
|
CCP Stillman
|
Posted - 2011.07.22 15:24:00 -
[12]
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
|
|
|
CCP Stillman
|
Posted - 2011.07.22 22:02:00 -
[13]
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 -
[14]
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 -
[15]
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
|
|
|
CCP Stillman
|
Posted - 2011.07.26 10:24:00 -
[16]
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 :) |
|
|
CCP Stillman
|
Posted - 2011.07.29 10:17:00 -
[17]
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 -
[18]
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!
|
|
|
CCP Stillman
|
Posted - 2011.08.04 11:10:00 -
[19]
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
|
|
|
CCP Stillman
|
Posted - 2011.08.05 10:02:00 -
[20]
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
|
|
|
|
CCP Stillman
|
Posted - 2011.08.08 10:52:00 -
[21]
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 -
[22]
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 -
[23]
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.
|
|
|
CCP Stillman
|
Posted - 2011.08.08 13:33:00 -
[24]
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...
|
|
|
CCP Stillman
|
Posted - 2011.08.11 10:02:00 -
[25]
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 -
[26]
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 -
[27]
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.
|
|
|
CCP Stillman
|
Posted - 2011.08.18 13:30:00 -
[28]
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 :(
|
|
|
CCP Stillman
|
Posted - 2011.08.23 10:27:00 -
[29]
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 -
[30]
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 -
[31]
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.
|
|
|
CCP Stillman
|
Posted - 2011.08.24 12:04:00 -
[32]
New build has been deployed with all fixes for stuff mentioned in here |
|
|
|
|