Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Mark Galean
Ooops Inc. Infinite Innovation
|
Posted - 2010.02.11 12:59:00 -
[1]
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)
This way one could create a key 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.
Mark Galean, Ooops Inc. Infinite Innovation (II) |
Xavier de'Lomas
Ooops Inc. Infinite Innovation
|
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
|
Posted - 2010.02.11 17:46:00 -
[4]
Yeah, the system could use some more customization.
|
Jonah Pod
|
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
Ooops Inc. Infinite Innovation
|
Posted - 2010.02.12 06:49:00 -
[6]
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.
Mark Galean, Ooops Inc. Infinite Innovation (II) |
Mark Galean
Ooops Inc. Infinite Innovation
|
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.
Mark Galean, Ooops Inc. Infinite Innovation (II) |
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
Ooops Inc. Infinite Innovation
|
Posted - 2010.02.14 05:39:00 -
[9]
Edited by: Mark Galean on 14/02/2010 05:45:25
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 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).
Mark Galean, Ooops Inc. Infinite Innovation (II) |
Constantinus Maximus
Paxian Expeditionary Force
|
Posted - 2010.02.15 00:04:00 -
[10]
Edited by: Constantinus Maximus on 15/02/2010 00:06:45 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.
|
|
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 IT Alliance
|
Posted - 2010.04.23 17:23:00 -
[13]
do it.
Northern Crusade - Daily numbers on EVE's largest current conflict |
Di Mulle
|
Posted - 2010.04.23 23:45:00 -
[14]
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |