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


 
Pages: 1 2 [3] 4 5 6

Author Topic

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****

Desmont McCallock
Posted - 2011.07.30 06:32:00 - [62]
 

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.

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) ?

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.

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 Wink 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 Smile 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 Wink On creating a new key pre-filling with a new random code would probably be good but not when trying to update it.

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.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.30 19:55:00 - [66]
 

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.

Also, given the structure of the xml returned (rowset name) and the pattern of past apis, should the call for the contracts.xml.aspx api be contractList.xml.aspx

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.

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.

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.

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.

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. Wink

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.

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2011.08.03 10:55:00 - [75]
 

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.

[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.

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>

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.

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>


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?

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2011.08.04 09:55:00 - [83]
 

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.

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 Sad

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 Sad


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.

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 Sad


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.

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.

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.


Pages: 1 2 [3] 4 5 6

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


 


The new forums are live

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

These forums are archived and read-only