These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Multiple possible API key mask bits
Author
Previous Topic Next Topic
Salgare
Center for Advanced Studies
Gallente Federation
#1 - 2016-07-11 07:40:23 UTC
In mapping the new scopes to api bit masks to automate, as much as possible, obtaining keys for/from the user, I've setup the constants given here:

https://eveonline-third-party-documentation.readthedocs.io/en/latest/xmlapi/authentication.html#access-mask-reference

(I submitted another column for all of them showing the hex values while I was at it)

When I generate the mask for my user, with that first bit mask always work? Always pick the last one? I assume maybe there are multiples for collision reasons? historical version reason etc?

Just looking for a heads up if I should know about conditions where I should pick the 2, 3 or in the case of "corporationMembersRead" the 5th Shocked bit mask.
Carbon Alabel
Gemini Talon
The Curatores Veritatis Auxiliary
#2 - 2016-07-11 12:23:27 UTC
The pipes indicate a bitwise or operation: you get all of them.
Salgare
Center for Advanced Studies
Gallente Federation
#3 - 2016-07-11 15:46:48 UTC
Carbon Alabel wrote:
The pipes indicate a bitwise or operation: you get all of them.


Ah so some given crest scopes cover multiple api enables, thanks Carbon
Salgare
Center for Advanced Studies
Gallente Federation
#4 - 2016-07-11 21:50:47 UTC  |  Edited by: Salgare
Carbon mentioned elsewhere:

Quote:

Also, these aren't CREST scopes. They are SSO scopes, which may be used to access private parts of both CREST and the XML API. Side note: the Create new application form on the developers site should be updated to reflect this.

For example, the characterContactsRead scope is utilized by both CREST and the XML API, the characterAssetsRead scope can only be utilized by the XML API, and the characterLocationRead scope can only be utilized by CREST. So no, there aren't any scopes missing in this list.


perhaps I'm wasting my time with this aspect of my framework. I assumed I would need to capture old api keyid/code's from users to use for the xml/api endpoints? Thus I'm mapping the applications scopes to the masks and calling https://community.eveonline.com/support/api-key/CreatePredefined?accessMask=0 (with the right mask) for the users convenience in then giving me the keyid/code

Are you saying that the SSO access_token can now be used with xml/api endpoints in-place of the old keyId/code?
Salgare
Center for Advanced Studies
Gallente Federation
#5 - 2016-07-11 23:39:51 UTC  |  Edited by: Salgare
For any others that might be interested, summary of this OP

1. If you have an SSO token it can be used in place of the KeyId/Code for all xml api calls except one call, Private Information -> Account status which still requires the KeyId/Code.

2. For overlapping endpoints where crest and xml cover the same data, use crest if you want "one call that's all" for those that have multiples and xml if you want the smaller/focused dataset. (assuming you are supporting both, which I will)

This is great news for most moving from IGB to external only web ... I assume not many applications will require that call and hence our users are mostly free of the legacy (woops said it) KeyId/Code.

The upcoming CrestJ framework is properties file configuration driven for the scopes the application requires. The framework can now look for that single Account exception being a requirement of the application and ask for/capture KeyId/Code only for those applications.


I'm not certain yet, but I believe this is the set of possible endpoints:

public enum Type (Public, Character, Corporate, Account, CrestOnlyCharacter, CrestOnlyCorporate, CrestOnlyPublic, XmlOnlyCharacter, XmlOnlyCorporate)

Some of which may only be future (i.e. some CrestOnlyPublic)


Thanks to those who helped me through this.
Salgare
Center for Advanced Studies
Gallente Federation
#6 - 2016-07-17 17:25:31 UTC
With the framework mostly in place, I'm down to implementing the endpoint marshaling (and possibly attempting submission of new group sourced doc tables)

The current xml-api documentation's scopes to mask map tables does not cover the following "API Key Management" items

Character

  • CharacterSheet 8 (0x00000008) endpoint covered in doc
  • CharacterInfo-public 8388608 (0x00800000)
  • CharacterInfo-private 16777216 (0x01000000)


Corporation

  • StarbaseList 524288 (0x00080000) endpoint covered in doc, likely should be included with scope corporatinStructuresRead


The two with endpoints covered in doc likely are just a mistake in the existing documentation.

1. Does anyone know what scope covers the CharacterSheet?
2. Does anyone know what the endpoints/data associated with those CharacterInfo's are?