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

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.

Kronus Heilgar
Dark Orbit Media
Posted - 2011.08.06 17:46:00 - [95]
 

Edited by: Kronus Heilgar on 06/08/2011 18:09:56
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.

EDIT: lulz. Ties to SISI, with an old mirror. Nevermind.

Elojs
Gallente
Corp 42
Posted - 2011.08.07 05:34:00 - [96]
 

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! Very Happy

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! Very Happy

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.

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! Very Happy

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

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

If not immediately, place it in the hopper with the rest of the requests.

Thanks in advance,
Elojs
Very Happy

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 Wink via the API in your application.

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

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... Very Happy

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)

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.

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 Very Happy

CCP Stillman

Posted - 2011.08.08 10:52:00 - [105]
 

Edited by: CCP Stillman on 08/08/2011 11:06:19
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.


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.


Agreed. That's what we'll do, sort of.

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

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 Very Happy


Thank you, the only way you could make my day any better is by telling me your also doing an employment history api. Very Happy

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 Very Happy

Thank you, the only way you could make my day any better is by telling me your also doing an employment history api. Very Happy


Embarassed I don't wanna promise too much. But... Very Happy

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 Very Happy

Thank you, the only way you could make my day any better is by telling me your also doing an employment history api. Very Happy


Embarassed I don't wanna promise too much. But... Very Happy


Very Happy

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

Embarassed I don't wanna promise too much. But... Very Happy


Very Happy

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 Very Happy

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 Very Happy

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. Very Happy

Originally by: CCP Stillman
Originally by: EVEVERIFY Cashier
Originally by: CCP Stillman

Embarassed I don't wanna promise too much. But... Very Happy


Very Happy

Here it is.



I think I hurt my back attempting to do a backflip Sad

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

Embarassed I don't wanna promise too much. But... Very Happy


Very Happy

Here it is.


OMG ur SO AMAZING THANK YOU THANK YOU THANK YOU I LOVE CAPS!!!!!!!

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 Wink

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 Evil or Very Mad

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.


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