EVE Search - New Dev Blog: Power to the End User

Check My IP Information

All Channels

EVE Information Portal

New Dev Blog: Power to the End User - Customizable Access API Keys

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] 2 3 4 5 :: one page

Author	Thread Statistics \| Show CCP posts - 8 post(s)

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. Fallout Associate Community Manager CCP Hf, EVE Online Contact us

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 :) --- SOMER Lotteries SOMER Blink - new! SOMER Escrow Services
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 Originally by: Nogap toosmall and your understanding of probability is on par with a radish.

Chribba Otherworld Enterprises Otherworld Empire	Posted - 2011.01.29 19:44:00 - [4] This looks VERY promising! /c Secure 3rd party service \| my in-game channel 'Holy Veldspar'

Di Mulle	Posted - 2011.01.29 19:49:00 - [5] Dammit, there are some impressive changes
TornSoul BIG Majesta Empire	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. BIG Lottery
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 Majesta Empire	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." BIG Lottery
Myxx Risen Angels	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. -- Originally by: CCP Explorer (and if you guys would also stop using Drakes it would be really appreciated, kthxbye).

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] 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 will use this. 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. --
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 belovFd applications neutered by this update? Sad day.
Jimmy Duce Navy of Xoc	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 Majesta Empire	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. BIG Lottery
darius mclever	Posted - 2011.01.29 21:46:00 - [20] <3 CCP

HyperBeanie Phantom Squad Systematic-Chaos	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 ;) EVSCO - Free and Paid killboards - Get yours today!
Nikolai Kondratiev Sphere Design Inc.	Posted - 2011.01.29 22:18:00 - [22] Quite some awesomeness here 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. _ Ore Table \| PI Profits
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 Kosh: The avalanche has already started. It is too late for the pebbles to vote. Tyrrax's bet status: PAID!
Cresalle	Posted - 2011.01.29 23:02:00 - [25] 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 ass-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).
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
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 Dirt Nap Squad.	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.
Ulair Memmet ORIGIN SYSTEMS	Posted - 2011.01.29 23:45:00 - [29] Very nice changes 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] 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. POS-Tracker 3.0 Hosting



Pages: [1] 2 3 4 5 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.