open All Channels
seplocked Assembly Hall
blankseplocked [proposal] Userconfigurable access to API data
 
This thread is older than 90 days and has been locked due to inactivity.


 
Author Topic

Mark Galean
Mercurialis Inc.
RAZOR Alliance
Posted - 2010.02.11 12:59:00 - [1]
 

Edited by: Mark Galean on 12/02/2010 06:56:54
After some thought, I've come to the conclusion that all these "Limited API required for service (X), (Y) and (Z)"-services that are popping up is kind of silly - I've ended up doing manual reports instead on characters/accounts I don't want to share character datas for - especially longtimers might have a hard time giving out this information - as in, it's not always trivial to do so.

My suggestion is adding a configurable-access API, with default set to show (by default) :
- pilot name
- pilot corporation
- pilot alliance

As such, no skills, no attributes, and no wallet content is delivered to offsite systems by default (meaning the Limited API becomes a simple "verification API-key").

Adding / creating a new API-key system with a "per key restrictionset" could be feasible, doing something like this :
[ ] allow polling all characters with this API
[x] allow only character named [CHARACTERNAME] to be polled with this key
[x] allow showing character name / corporation name / alliance name (set to yes by default)
[ ] allow showing skills
[ ] allow showing certificates
[ ] allow showing wallet content
[ ] allow showing assets
[ ] allow showing journal
[ ] allow showing industry/science jobs

etc etc etc - with rolesettings for both characters and corporations (should the queried character be a CEO)
(I already know that the "full API" is required for most of this though, it can however be removed once a rolebased API-method like this would exist)

It'll be autogenerated keys when created, as per today, but allowing multiple sets where the userID holds information of which character, the enhanced/adjustable API holds which access the API has (done as above, with ticked selectboxes) - in short, it would replace BOTH the limited and full API keys.

This would then be able to replace / enhance the following suggestions :

http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1265665 [Proposal] New API key
http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1260396 [Proposal] BPO/BPC API
http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1223266 [Proposal] Certificates - New permissions
(There are surely other posts that contains API-related requests/proposals, but I added the ones I found API-wise up to and including 10 pages back at the time of writing)

This way one could create multiple keys for most 'methods' one would like, and also being able to modify it when wanted, increasing access to whomever needs the information, and as such not having to give out information about all characters on an account.

Edit: Added explanation as to which other posts it might replace, and also a slightly better explanation of the multiple API-keys (website-handling).

Xavier de'Lomas
Quantum Horizons

Posted - 2010.02.11 13:03:00 - [2]
 

/signed.

At least a basic verification option would be good enough for forum/ts/vent registrations. I really don't want to give out detailed skill training and my current wallet balance to every alliance I happen to fleet up with.

ByteMan
Posted - 2010.02.11 16:47:00 - [3]
 

I like the configurable option, with the basic info as the default. In fact, I'm surprised that all that informaiton is provided by default.

However, how would you handle cases where you may want to provide different levels of informaiton for different purposes, eg. name/corp/alliance for boards and ts, but more info for others like EFT, etc.

Herschel Yamamoto
Agent-Orange
Nabaal Syndicate
Posted - 2010.02.11 17:46:00 - [4]
 

Yeah, the system could use some more customization.

Jonah Pod
Gallente
Posted - 2010.02.11 20:02:00 - [5]
 

Edited by: Jonah Pod on 11/02/2010 20:02:24
Mark Galean, could you please add links to the relevant threads (the ones that would be rendered obsolete if you proposal would be implemented) to your proposal? Would add some weight to the proposal as such ;)

The only obvious caveat I see onn first glance is that it'll guarantee a flood of "we want moarr keys!" threads as all those shiny tools and apps require different types of information and you'll just have your "public" key to share... (e.g. a killboard asks for different information than in-eve.net and the other application asks for different information again - this will have you end up with basically spreading all of your valuable information all over the world... or makes you cry for even moarr keys).

Apart from that, this is currently the best proposal I read. Flexible and powerful.

Supported.

Mark Galean
Mercurialis Inc.
RAZOR Alliance
Posted - 2010.02.12 06:49:00 - [6]
 

Edited by: Mark Galean on 28/02/2010 01:35:49
Originally by: Jonah Pod
Edited by: Jonah Pod on 11/02/2010 20:02:24
Mark Galean, could you please add links to the relevant threads (the ones that would be rendered obsolete if you proposal would be implemented) to your proposal? Would add some weight to the proposal as such ;)

Done, and added a small additional information on how multiple keys are handled.

Edit: Doh, I should ofcourse support my own proposal (not that it matters, I guess it's not counted anyway)

Mark Galean
Mercurialis Inc.
RAZOR Alliance
Posted - 2010.02.12 07:08:00 - [7]
 

Originally by: ByteMan
However, how would you handle cases where you may want to provide different levels of informaiton for different purposes, eg. name/corp/alliance for boards and ts, but more info for others like EFT, etc.

Multiple keys are generated, and each of them have different access-levels, and being tagged with whatever you want to name them for future reference.

Dr BattleSmith
PAX Interstellar Services
Posted - 2010.02.14 02:11:00 - [8]
 

With oAuth and separate scopes the user could choose which parts of the API to allow on a per-site basis.
Without the need for any copy+paste of API keys as the keys are generated and swapped by the code in the background.
From a simple user interface that very basically prompts the user without any complexity.

This would bring the new SpaceBook into line with other social networks.

The old API key system should be replaced rather then hacked at.

Mark Galean
Mercurialis Inc.
RAZOR Alliance
Posted - 2010.02.14 05:39:00 - [9]
 

Edited by: Mark Galean on 14/02/2010 06:03:15
Originally by: Dr BattleSmith
With oAuth and separate scopes the user could choose which parts of the API to allow on a per-site basis

The main idea about this proposal is about extending the API so it can allow for just that - separation of privileges to read specific parts of the users API. If it's done by oAuth or an inhouse-mechanism is (for the user) a non-issue, as long as the user controls what is given out infowise.

In oAuth this is done using tokens that the user must create and manage (or a realtime selector (ajax anyone? :P) on CCPs site) for the restrictions that a calling service (external webserver or software) should have on their request. Thus meaning that a selector must/should exist from CCPs side (the token creator mechanism), which is what I propose above.
In short the user must first create the token within his/her rolemanager (in CCPs backend), create a specific token, and then tell that to the calling service (same functionality as the current API gives).
(A calling service will see only the info given out by the grants from the token itself - this is how oAuth works).

- oauth_token
The temporary credentials identifier.

- oauth_token_secret
The temporary credentials shared-secret.

As you can see, these credentials are close to the same as is active per today, where the user has already created a set of tokens (FULL/LIMITED) and given them to sites/tools/software that exists, with access to poll specific data only. Again as mentioned in my first post, and now clarified.

If you still think my interpretation is wrong, you might read the IETF Draft regarding oAuth and the examples for Google Apps with oAuth.
Specifically this example (which is VERY similar to what already exists).

Constantinus Maximus
Paxian Expeditionary Force
Posted - 2010.02.15 00:04:00 - [10]
 

Edited by: Constantinus Maximus on 15/02/2010 00:08:16
Yeah similar. The oAuth flow is even simplier then that tho.

* 3rd party site/software.
* User clicks a link/button to request access to API info.
* User is shown a list of scopes being requested by the 3rd party site/software (skills/wallet/corp/pos)
* User clicks approve/decline.
* User is Autheniticated sercurely.

The user can then manage the linked sites permissions from their account section of the Eve website.

All keys are hidden in the background without the user needing to worry about the technical aspects.

This then allows a whole world of social network programming which will be locked away from Eve,
unless CCP adopt some open standards in relation to the API and the new social network.


edit: oh and yeah you're right, the API already uses a token system so going to a standard one wouldn't be too major a change.

Added bonus is that the data being passed is encrypted using the shared secret key.

Constantinus Maximus
Paxian Expeditionary Force
Posted - 2010.02.15 01:15:00 - [11]
 

I've mixed terminology a little.

What I'm describing is oAuth + OpenID.

The concept is "If you can prove you own this URL then we'll let you into our website without a password".
In Eve's case the user would be proving they own a particular character without exposing any private info.

This OpenID process then includes oAuth tokens which can be used to "impersonate" the user on the API.
Making requests with the same credentials the user would have by use of the token. Once approved by the user.

This has the extra added benefit of 3rd party sites not having 101 different logins and passwords,
removing the risk of people being phished when using poorly selected username/password.



Ravenal
The Fated
E.Y
Posted - 2010.02.28 01:32:00 - [12]
 

can we just have a "thumbs up/thumbs down" links on the OP please instead of having to reply.

Peter Powers
FinFleet
Raiden.
Posted - 2010.04.23 17:23:00 - [13]
 

do it.

Di Mulle
Posted - 2010.04.23 23:45:00 - [14]
 



 

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