open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Power to the End User - Customizable Access API Keys
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2 3 4 5

Author Topic

CCP Fallout

Posted - 2011.01.29 19:10:00 - [1]
 

More changes are coming to the API, and CCP Prism X's newest dev blog has all the details.

Somerset Mahm
Somer's Omnibus Exploration and Reclamation
Cognitive Distortion
Posted - 2011.01.29 19:18:00 - [2]
 

All *very* good news for us app developers. Cheers :)

Cryten Jones
Gallente
Advantage Inc
The Matari Consortium
Posted - 2011.01.29 19:41:00 - [3]
 

How about making the system work the other way around?

You give out the access key for your character, Corp or account.
The application requests access via the api.
The request to the api includes the application name and a one time key
the api registers the new request and creates an entry in your api management page.
You receive an eve-mail saying you have waiting api requests.
You login to review the request. If you are happy you choose the access options and time length and approve the access.

Nice challenge-response style access.

-CJ


Chribba
Otherworld Enterprises
Otherworld Empire
Posted - 2011.01.29 19:44:00 - [4]
 

This looks VERY promising!

/c

Di Mulle
Posted - 2011.01.29 19:49:00 - [5]
 

Dammit, there are some impressive changes Shocked

TornSoul
BIG
Gentlemen's Agreement
Posted - 2011.01.29 19:50:00 - [6]
 

Edited by: TornSoul on 29/01/2011 19:52:50
The timing is just uncanny.

Last few days I've (re-)started thinkering with updating BLEEP to provide complete differentiated API page access.

--------

So a few notes

"Maximum lifetime of a year."
Please do not do this.
There is no real need for a maximum lifetime - And in some instances it will be *very* annoying.
I have several applications running myself (like the BIG Lottery) that I would hate to have to remember to update the keys on once a year (what are the chances one doesn't remember until things suddenly doesn't work...)


"But requiring non-super users to pick from 25 calls in order to make an active key is going to be too confusing for many. So instead we're grouping the calls together according to functionality."
I'm all for adding "groups" for easy selecting for the non-super users, but please do no close out the super users..

1: Chances are you'll get it (the grouping) wrong anyhow - Or at least people will disagree how it should be.
2: Why limit it? As mentioned above, people are *bound* to disagree what the best grouping will be.

So please allow both options.
The easy "pick a group" and the more involved "pick from these 50 pages".

---------

EDIT :
Other features I was considering for BLEEP you might want to consider
- One use keys.
- Ability to "bind" keys to certain sites (IP/URL). Ie if the originator of the API call is not in that list, it's denied.


Gnulpie
Minmatar
Miner Tech
Posted - 2011.01.29 20:02:00 - [7]
 

A W E S O M E


This is absolutely the right direction. Very good changes. Bravo!

Kelduum Revaan
EVE University
Ivy League
Posted - 2011.01.29 20:04:00 - [8]
 

Very interesting, and looks like some nice changes.

Once question though: Will there still be some kind of unique identifier in the API results, so we can still identify an individual account?

At present, we use this (amongst with other things) to add people to our "Do Not Recruit" list, so they cant simply biomass/transfer their characters and look like another account.

I assume the existing AccountStats could/will be extended to include this?

TornSoul
BIG
Gentlemen's Agreement
Posted - 2011.01.29 20:16:00 - [9]
 

Originally by: TornSoul

- Ability to "bind" keys to certain sites (IP/URL). Ie if the originator of the API call is not in that list, it's denied.



Hmm perhaps thats what's meant by
"Assign call groups to your key."



Myxx
Atropos Group
Posted - 2011.01.29 20:26:00 - [10]
 

Originally by: Kelduum Revaan
Very interesting, and looks like some nice changes.

Once question though: Will there still be some kind of unique identifier in the API results, so we can still identify an individual account?

At present, we use this (amongst with other things) to add people to our "Do Not Recruit" list, so they cant simply biomass/transfer their characters and look like another account.

I assume the existing AccountStats could/will be extended to include this?


^^ This...

As a CEO, I use the API to verify accounts being who they claim to be, and to do background checks on people via searching for names, forum posts, etc.

Ackmarr
Caldari
Posted - 2011.01.29 20:31:00 - [11]
 

Will there be an api call to know what the key gives access too.

I think there should be a way to know, from the api management, what system use the keys.
Developers could have an interface to create apps id with domains that can authenticate with the apps id.

Herschel Yamamoto
Agent-Orange
Nabaal Syndicate
Posted - 2011.01.29 20:35:00 - [12]
 

Quote:
Maximum lifetime of a year.


I like everything in the dev blog except this. Please don't do this. I don't want to have to screw around with my Evemon annually for no good reason, and that applies double to people who collect large numbers of API keys from various people, for reasons like corp security.

Other than that, though, this is something I've been wanting to see for a long time, and I'm all for it. Well done.

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2011.01.29 20:36:00 - [13]
 

Edited by: Catari Taga on 29/01/2011 21:28:38
Yes!!! This blog came much faster than expected, nice surprise.

Quote:
An expiry date will be added to all API keys.

While this makes sense from a security perspective, for the majority of players in EVE security isn't all that important. Please allow keys to not expire by default. I know most of the people that I hold API keys from would set them to not expire if given the chance.

Quote:
Allowing character specific keys rather than always account wide.
  • This setting will only be viewable through the API key management, not by everyone holding the key. So the holder of a character specific key will not be able to see what other characters belong to the account if the keys owner sets it to a single character.


I hope this does not mean that the key holder cannot even verify what type of key they hold, because that is obviously important for recruit vetting.

Quote:
Group: Character sheet

Needs SkillQueue/InTraining keys as well.


Originally by: Cryten Jones
How about making the system work the other way around?

You give out the access key for your character, Corp or account.
The application requests access via the api.
The request to the api includes the application name and a one time key
the api registers the new request and creates an entry in your api management page.
You receive an eve-mail saying you have waiting api requests.
You login to review the request. If you are happy you choose the access options and time length and approve the access.

Nice challenge-response style access.

-CJ




definitely this.

Originally by: Kelduum Revaan
Once question though: Will there still be some kind of unique identifier in the API results, so we can still identify an individual account?

At present, we use this (amongst with other things) to add people to our "Do Not Recruit" list, so they cant simply biomass/transfer their characters and look like another account.


and this as well.

Originally by: Ackmarr
Will there be an api call to know what the key gives access too.


and please this

Marcel Devereux
Aideron Robotics
Posted - 2011.01.29 20:40:00 - [14]
 

1. Please no maximum lifetime. It just becomes more of a burden for the user to update their keys.
2. Please provide a way for applications to query what feeds a key has access to. This will allow applications notify the user on key entry about what features will be disable for the character.
3. Don't forget this: http://bit.ly/gHFWxa ;-)

mkmin
Posted - 2011.01.29 20:41:00 - [15]
 

The one thing that really stands out as a red flag to me is this:

Quote:

The new API keys will be managed through EVE Gate.



From day 1 of spacebook, security has been anathema to it's very design philosophy, and remains so to this day. Players' security settings on SISI have recently been reset to the default of buck-ass naked regardless of what decisions the player has actually made. That's just 1 example of why spacebook is **** and has no credibility. Why should players believe you won't just screw it up again and accidentally make all our API information public too? Wouldn't be your first screw up with spacebook, and isn't in the realm of absurdity.

API key management should be in the account management where it's relatively safe, instead of on spacebook which has the security of a preschool.

Isaac Kleiner
Gallente
GRIM MARCH
Grim Enterprises
Posted - 2011.01.29 20:48:00 - [16]
 

So I guess this means that those of us still using legacy API-based apps (RIP, Capsuleer) will see our belovèd applications neutered by this update? Sad day. Sad

Jimmy Duce
Chaotic Tranquility
Posted - 2011.01.29 20:55:00 - [17]
 

SO I know the name change and crap means well. But can there be a default that doesn't change anything?

2 options,

Limited API
Full API


Well I guess 3

Customised


Also, Really don't put an expiration date. Obvisouly allow me to change my "api" or atleast give me the option to never expire.

Matalino
Posted - 2011.01.29 21:15:00 - [18]
 

Edited by: Matalino on 29/01/2011 21:24:01
Quote:
"Maximum lifetime of a year."
+1 request for no lifetime limitation.

I think that it is good that the default has a finite expiration. However, I would like to have the option to create a key that does not have an expiration. Most of the time I would rather continue to use the API key indefinately and reset it manually when I feel there is a need. This would be especially true with the option to create a seperate key for each application, and limit the accessable pages those to only those needed by the application.
Quote:

•Group: Character sheet
◦/char/CharacterSheet.xml.aspx
◦/char/Standings.xml.aspx
•Group: Wallet
◦/char/WalletTransactions.xml.aspx
◦/char/WalletTransactions.csv.aspx
◦/char/WalletJournal.xml.aspx
◦/char/WalletJournal.csv.aspx
◦/char/AccountBalance.xml.aspx
•Group: Science and Industry
◦/char/Research.xml.aspx
◦/char/IndustryJobs.xml.aspx
•Etc...


The grouping looks good. I would add the suggestion that you allow us to drill in and select pages within each grouping. Regular users can select/deselect the page groups that they wish to associate with a key. Power users can expand the group and select/deselect pages with the group. This would work best if you continue with the design plan to exclude pages from appearing in more than one group.
Originally by: Ackmarr
Will there be an api call to know what the key gives access too.

I think there should be a way to know, from the api management, what system use the keys.
Developers could have an interface to create apps id with domains that can authenticate with the apps id.
This is also strongly recommended. It would be more effective than testing each page and watching for errors, and then retesting each page to see if the permissions have changed.

TornSoul
BIG
Gentlemen's Agreement
Posted - 2011.01.29 21:32:00 - [19]
 

Originally by: Matalino
Originally by: Ackmarr
Will there be an api call to know what the key gives access too.

I think there should be a way to know, from the api management, what system use the keys.
Developers could have an interface to create apps id with domains that can authenticate with the apps id.
This is also strongly recommended. It would be more effective than testing each page and watching for errors, and then retesting each page to see if the permissions have changed.

This.
As that's exactly what's going to happen otherwise.

darius mclever
Posted - 2011.01.29 21:46:00 - [20]
 

<3 CCP

HyperBeanie
Phantom Squad
En Garde
Posted - 2011.01.29 21:50:00 - [21]
 

Will 3rd party sites be able to send the user to Eve Gate with a pre-filled request of what the site needs?
(Like the facebook apps does).

fx. eve-kill needs access to your kills. User goes to eve-kill, clicks a link and gets sent to eve-gate where the appropriate checkboxes have been marked and are ready. User can now do a simple copy/paste (or redirect back?) on ok.

Just an idea ;)

Nikolai Kondratiev
Sphere Design Inc.
Posted - 2011.01.29 22:18:00 - [22]
 

Quite some awesomeness here Cool

Also, like someone said, please make sure there is a way to have unlimited (in time) keys. In many case where there isn't trust issue, it would be annoying to have to create a new key every X months and update all the 3rd aprty apps using it.

Bragii
Gallente
Trumpets and Bookmarks
Posted - 2011.01.29 22:44:00 - [23]
 

Currently corp recruitment is very one sided when it comes to API information exchange.
Can we have a public key related to every player corp that gives a potential recruit some information about the corp.
e.g.
Provide a basic multiple choice survey to members leaving a corp asking their opinions of the corp, what it's general activities are (e.g. worm holing ...), reason why they left the corp and did they think overall it treated them fairly, etc.
Then provide the statistical results of these exit surveys both via the API and in game.

Pilk
Evolution
IT Alliance
Posted - 2011.01.29 22:56:00 - [24]
 

+1 for no forced expiration on keys. And it's not helpful, anyway; it typically just results in people using serialized passwords ("mysupersecretpass12", then "mysupersecretpass13", etc.). Even Microsoft says it's a pointless/negative security measure.

I'd also agree with the possibility of having sites request the set of privileges they need. If "dialing in" is not an option, another might be that a "quickcode" of some type could encode what pages need to be accessed; a site would then publish its quickcode, which would provide an alternative to it saying, "OK, now check box #3, and uncheck box #4 that appears when you check #3, and....".

--P

Cresalle
Posted - 2011.01.29 23:02:00 - [25]
 

Edited by: Cresalle on 29/01/2011 23:09:32
Firstly a question: Is this really at the top of the priority list?

Secondly reinforcing a point made by an earlier post: I'd rather not have generating an API key become an un-navigable labyrinth of garbage a-la POS/roles config.

Thirdly, a point of interest: Your reasoning re applicants is fatally flawed. People who want full API now will want full API in the future, including mail. People are like that. Especially the kind of a**-hats that run large alliances/coalition and anally retentive corps.

Finally: I'd much rather see you set up a custom query system so that an app can make a single request and get a packaged response containing data from multiple API sets rather than having to make 700 different API queries. It would be faster for the end-user and lighter on the server (fewer sock open/close, since nobody on the gdmf internet knows how to use keep-alive).

Edit:
-----------------------------------------
Oh, and forced expiration is stupid.

Sturmwolke
Posted - 2011.01.29 23:04:00 - [26]
 

If you're increasing the complexity for API managament by switching to fully customizable options, then I would suggest creating a few EVE standard, one-button easy/quick pick, no hassle static choices for newbies and veteran players alike.

There needs to be at least a few basic standard pick to keep people from trippping all over with the customizations and whatnots - the concept is similar to the EVE skill certificate system if you're having trouble picturing the intention.

Example for picks :

1) Limited Character API (basically the same info as current limited API gives + expiry duration)
2) Limited Character API + Science & Industry API (same as point 1. but only adds Science and Industry stuffs)
3) Limited Character API + Market (same as point 1. but only adds Market stuffs)
4) Full Account API (covers everything + expiry duration)

The above are just arbitrary examples to illustrate the basic standardization.
Ideally, keep the standard choices max around 3-5 (as more than this just defeats the entire purpose of it).

P.S 1 year max expiry for all keys is good for security, but I'm wondering how practical is it to renew these keys when you've got it spread across different apps and characters - assuming its mandatory. If not, then one way to mitigate risk for keys that do not expire is to have an option to lock to a particular IP address or set of IP addresses .... or even a unique computer hardware identifier hash. Useless to dynamic IP users, but hey where security is concerned, the more paranoid the better Wink

Tricia Trace
Posted - 2011.01.29 23:08:00 - [27]
 

I really like this!

+1 for no max lifespan
+1 for allowing advanced users to customize the api key access rights

Originally by: Cryten Jones
How about making the system work the other way around?

You give out the access key for your character, Corp or account.
The application requests access via the api.
The request to the api includes the application name and a one time key
the api registers the new request and creates an entry in your api management page.
You receive an eve-mail saying you have waiting api requests.
You login to review the request. If you are happy you choose the access options and time length and approve the access.

Nice challenge-response style access.

-CJ


+1 for challenge-response implementation

Elojs
Gallente
Corp 42
Posted - 2011.01.29 23:16:00 - [28]
 

I like what I've seen here. A lot.

However, there's a layer of functionality that is lacking. It's all very well that you can block a key that's become compromised. How about a detailed log of who is using those keys, so you can track them down and (in game) kill 'em?

For example, I get a key from someone, then sell it to another player. They take the key (while its still valid) and work some game magic to the original someone's disadvantage. Someone becomes aware of the key compromise, and voids the key. But there he's pretty much done. The damage is done, and there is no backtrail that can be traced that leads to the culprit.

Unless the new system allows effectively unlimited keys to the player, allowing them to disseminate them singly to parties needing access to the data, as well as a log detailing accesses and which keys are used for that access, the player has no more control than he does now. Some of us can investigate when sufficient information is available. All I'm asking for is that the sufficient information be made available. Smile

Ulair Memmet
ORIGIN SYSTEMS
Posted - 2011.01.29 23:45:00 - [29]
 

Very nice changes Very Happy
I've wanted this for a long time. Thank you!

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.01.30 00:19:00 - [30]
 

Edited by: Johnathan Roark on 30/01/2011 00:28:19
I would like to add a request to at least get the 3rd party app developers be very involved in testing this so we are prepared for it going live and hopefully we can work out all the bugs. Also, I strongly dislike EVEGATE and find it takes way too long to get into, I'd rather not have to go to it to get my api keys.

Originally by: TornSoul
Edited by: TornSoul on 29/01/2011 19:52:50
The timing is just uncanny.

Last few days I've (re-)started thinkering with updating BLEEP to provide complete differentiated API page access.

--------

So a few notes

"Maximum lifetime of a year."
Please do not do this.
There is no real need for a maximum lifetime - And in some instances it will be *very* annoying.
I have several applications running myself (like the BIG Lottery) that I would hate to have to remember to update the keys on once a year (what are the chances one doesn't remember until things suddenly doesn't work...)


"But requiring non-super users to pick from 25 calls in order to make an active key is going to be too confusing for many. So instead we're grouping the calls together according to functionality."
I'm all for adding "groups" for easy selecting for the non-super users, but please do no close out the super users..

1: Chances are you'll get it (the grouping) wrong anyhow - Or at least people will disagree how it should be.
2: Why limit it? As mentioned above, people are *bound* to disagree what the best grouping will be.

So please allow both options.
The easy "pick a group" and the more involved "pick from these 50 pages".

---------

EDIT :
Other features I was considering for BLEEP you might want to consider
- One use keys.
- Ability to "bind" keys to certain sites (IP/URL). Ie if the originator of the API call is not in that list, it's denied.




I completely agree with all of this, especially the grouping, make default groups, but let us go into each "group" and decide if we want to remove a few things.

As far as the lifetime, at the very least, we need an api that we can query to find out details of the api: when it will expire and what it has access to. Currently I have a two test calls that I make to determine if the key is valid and if its limited or full.

Originally by: Kelduum Revaan
Very interesting, and looks like some nice changes.

Once question though: Will there still be some kind of unique identifier in the API results, so we can still identify an individual account?

At present, we use this (amongst with other things) to add people to our "Do Not Recruit" list, so they cant simply biomass/transfer their characters and look like another account.

I assume the existing AccountStats could/will be extended to include this?


Yes, we need to have some sort of accountID. I prefer it be very accessible so we don't have to worry about having access to it.

Originally by: Cryten Jones
How about making the system work the other way around?

You give out the access key for your character, Corp or account.
The application requests access via the api.
The request to the api includes the application name and a one time key
the api registers the new request and creates an entry in your api management page.
You receive an eve-mail saying you have waiting api requests.
You login to review the request. If you are happy you choose the access options and time length and approve the access.

Nice challenge-response style access.

-CJ




No, too much work for everyone.


Pages: [1] 2 3 4 5

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