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


CCP Stillman	Posted - 2011.01.30 00:19:00 - [31] I'm just gonna address some of the ones I can. Prism will respond more detailed Monday I'm sure. Originally by: Elojs 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? Very few people know this, but that's possible with the current API. And we're not planning to remove features.


CCP Stillman	Posted - 2011.01.30 00:23:00 - [32] Originally by: HyperBeanie 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 ;) We have no specific design. But one of the very first things our beloved Senior Producer, CCP Zulu, mentioned when he saw our plan, was very much along the lines of what you describe, only he called it "templates". As for how it will exactly will work is to be decided. But it will happen.


CCP Stillman	Posted - 2011.01.30 00:29:00 - [33] Originally by: Cresalle Edited by: Cresalle on 29/01/2011 23:09:32 Firstly a question: Is this really at the top of the priority list? Are you suggesting it shouldn't be, even if it's the single most requested piece of functionality which people have been begging for?

DaDutchDude Agony Unleashed Agony Empire	Posted - 2011.01.30 01:26:00 - [34] I haven't completely wrapped my head around all the ins and outs yet, but from a first glance, the only thing I can come up with is FAN-****ing-TASTIC! It's like you read my mind (or perhaps my topic) ;) :P _______________________________________________ - Beware of programmers running with scissors -
Kaahles Fulcrum Weapon Systems Inc.	Posted - 2011.01.30 01:35:00 - [35] About damn time. Short question and I guess the answer is probably yes (otherwise you should really check what drugs you guys take). There will be an API site that will let me check the key statistics/data right? Like: what character / corp / account it is bound to? Or stuff like expiration time of the key (can get pretty handy if let's say evemon reminds you a week ahead of it to update the friggn key). But what really is needed: An API call which returns a list of all the data sets accessible by that particular key. It would be pretty stupid when I write a program and it doesn't know if it can actually access certain information until it tries to get them. ----------------------------- OMG THE SKY IS FALLING! Contract me all your stuff so I can save it!
DmitryEKT Point of No Return Waterboard	Posted - 2011.01.30 01:44:00 - [36] Will you be adding an interface to evegate which allows us to view all information contained in the api without either a) sending an api key to a 3rd party application, or b) having to read xml files? i.e., can we have a page integrated into evegate which adds a readable layout to the api xml format so that we can see what each page of the api data we're giving out actually contains? This is especially relevant, because some of the data accessible through api (like the number + overall duration of our logins) is not viewable ingame, or through evegate, or anywhere else. It is api-exclusive account data.
Iam Widdershins Project Nemesis WE FORM VOLTRON	Posted - 2011.01.30 02:53:00 - [37] I think it will be important and useful to be able to have an API key that only produces your CCP-vetted killmails; I'd love for that to be a separate category. Hopefully that's in the plan.
Ronan Teisdari The Graduates Morsus Mihi	Posted - 2011.01.30 03:19:00 - [38] Nice to see some changes coming to the API system finally. However, We do need a way to verify all of the characters on an account. I do not know of any 0.0 corporation that does not verify alts on accounts. If we have to go back to requesting screen shots, a lot of unhappy people will show up. Nothing special is needed, but we do need to know at least the names on the accounts. That means, we still need to be able to query: /account/Characters.xml.aspx Restricting access beyond that is fine, but we do need to be able to verify 'who' is on the account.
Ix Forres Caldari Righteous Chaps	Posted - 2011.01.30 03:42:00 - [39] Originally by: Johnathan Roark No, too much work for everyone. Tell that to every developer using Twitter or any other OAuth/OpenID based system. If CCP had just taken OAuth and put their security model atop that (entirely doable) then third party devs would just need to pick up an OAuth library and in 20 seconds flat you'd have a working API client. So why wasn't OAuth (or any other existing standard for this sort of authentication) chosen? Back when I did Gatecamper, which implemented a challenge-response proxy for API authentication, it was very simple for users - click link, get list of what the app wants, say yes or no (or for some apps, select optional permissions), press button, app now knows what you gave it access to and has a unique token used for that application. That was a very simple proof of concept and is exactly the sort of thing OAuth is designed to do. So why has CCP avoided open standards and gone for yet another completely bizarre way of doing it? (I don't really care, I don't write apps any more, but if I were writing apps this would be a major facepalm moment. Moving in the right direction, but using a pogo stick to hop up the hillside when you could just walk...) -- Ix Forres - Used to be a third party developer, now a full-time bittervet
Marcel Devereux Aideron Robotics	Posted - 2011.01.30 04:09:00 - [40] Originally by: Ix Forres Originally by: Johnathan Roark No, too much work for everyone. Tell that to every developer using Twitter or any other OAuth/OpenID based system. If CCP had just taken OAuth and put their security model atop that (entirely doable) then third party devs would just need to pick up an OAuth library and in 20 seconds flat you'd have a working API client. So why wasn't OAuth (or any other existing standard for this sort of authentication) chosen? Back when I did Gatecamper, which implemented a challenge-response proxy for API authentication, it was very simple for users - click link, get list of what the app wants, say yes or no (or for some apps, select optional permissions), press button, app now knows what you gave it access to and has a unique token used for that application. That was a very simple proof of concept and is exactly the sort of thing OAuth is designed to do. So why has CCP avoided open standards and gone for yet another completely bizarre way of doing it? (I don't really care, I don't write apps any more, but if I were writing apps this would be a major facepalm moment. Moving in the right direction, but using a pogo stick to hop up the hillside when you could just walk...) Agreed. OAuth 2.0 (or a variant) should be seriously considered. Having users manually manage their keys is ridiculously. But then again EVE is a place where humans do all the manual work while the computers just sit back an relax.

Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.01.30 04:55:00 - [41] Originally by: Ix Forres Originally by: Johnathan Roark No, too much work for everyone. Tell that to every developer using Twitter or any other OAuth/OpenID based system. If CCP had just taken OAuth and put their security model atop that (entirely doable) then third party devs would just need to pick up an OAuth library and in 20 seconds flat you'd have a working API client. So why wasn't OAuth (or any other existing standard for this sort of authentication) chosen? Back when I did Gatecamper, which implemented a challenge-response proxy for API authentication, it was very simple for users - click link, get list of what the app wants, say yes or no (or for some apps, select optional permissions), press button, app now knows what you gave it access to and has a unique token used for that application. That was a very simple proof of concept and is exactly the sort of thing OAuth is designed to do. So why has CCP avoided open standards and gone for yet another completely bizarre way of doing it? (I don't really care, I don't write apps any more, but if I were writing apps this would be a major facepalm moment. Moving in the right direction, but using a pogo stick to hop up the hillside when you could just walk...) An OAuth system would be fine for this as long as ccp is a provider, Im not going to use my facebook account for this. What I object to in my quoted response is the way the other poster's post read is that id need to log into evegate api manager, grab a key of some sort, go to the app, put that in, wait for the app to query, then go back to evegate and grant access to that app. My biggest concern with OAuth is phishing, you'll have users that won't realize that they are not putting there info into ccp's site (people are stupid). POS-Tracker 3.0 Hosting
Cyaxares II	Posted - 2011.01.30 09:27:00 - [42] Very nice changes! & CCP does listen! hope the actually released version will live up to the expectation set by this blog.
Cresalle	Posted - 2011.01.30 09:40:00 - [43] Edited by: Cresalle on 30/01/2011 09:43:18 Originally by: CCP Stillman Originally by: Cresalle Edited by: Cresalle on 29/01/2011 23:09:32 Firstly a question: Is this really at the top of the priority list? Are you suggesting it shouldn't be, even if it's the single most requested piece of functionality which people have been begging for? reads other posters in thread Okay... I guess I'm just out of touch. I give up. (What the hell?)
HyperBeanie Phantom Squad Systematic-Chaos	Posted - 2011.01.30 09:54:00 - [44] Originally by: CCP Stillman Originally by: HyperBeanie 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 ;) We have no specific design. But one of the very first things our beloved Senior Producer, CCP Zulu, mentioned when he saw our plan, was very much along the lines of what you describe, only he called it "templates". As for how it will exactly will work is to be decided. But it will happen. If i ever make it to fanfest (or you guys make it to Copenhagen) i'll buy you a beer! (and one for Zulu also) /Beanie EVSCO - Free and Paid killboards - Get yours today!
Vessper Indicium Technologies	Posted - 2011.01.30 11:23:00 - [45] I like the changes except for the maximum lifetime limit of the keys. By all means allow people to set an expiry date if they want to, but if the keys are for personal use for example, I can't see why you'd want (or need) to place such a restriction. Would the key expiry date be available through the API so third parties are able to see it? EveHQ Character App
Seraphina Amaranth	Posted - 2011.01.30 12:30:00 - [46] +1 for OAuth. Standards are good, especially when libraries for said standards are already written.
Thebriwan LUX Uls Xystus	Posted - 2011.01.30 12:50:00 - [47] From a developers perspective I welcome the proposed changes. The only Flaw I see so far is the forced expiration of the keys. I'd like to have this gone. Make an expiration of "never" possible. From a users perspective I see the added security as a plus. BUT this is going to be a MESS in usability. It is so often that I see questions on the forum about something that SHOULD be clear by just looking at it, but for some not tech people its hard to get a grip on it. So you need to make this as easy as possible. Maybe with predefined key settings or something.
Qoi Exert Force	Posted - 2011.01.30 13:15:00 - [48] Edited by: Qoi on 30/01/2011 13:16:23 "Corporation Key (Requires Director role)" Currently you can access the corp API without Director Role (For example with the Accountant, Junior Accountant or Trader Role) - i think this should not be removed? It doesn't affect me, but you should certainly communicate this bit better if you don't like threadnaughts ;) OAuth doesn't seem to be a good solution for this kind of thing, can i easily generate an OAuth permission on the eveonline website with the correct permissions (In which case OAuth will just needlessly complicate the process) and then transfer that ASCII based to another machine? Ix example doesn't seem to fit this usecase at all, but then, he is just a bitter veteran. I also would love to have more granular access to API calls (not just groups), but i'm a web developer, security and principle of least access are just stamped into my brain. Maybe it would needlessly complicated the process for end users. Edit: Oh, having the possibility for a key that has an infinite lifespan (For completely uncritical (i.e. killlog) keys) should be possible :) All the rest is so ****ing brilliant and needed, we all should buy PrismX and Stillman liquids of their choice at the fanfest.
Siiee Recycled Heroes	Posted - 2011.01.30 14:07:00 - [49] +1 non-expiring keys With 9 chars and near a dozen API sync'd applications of various types I have precisely 0 interest in updating my keys for my own personal use on an annual basis. The default setting should be some safe value but I don't need CCP to protect me from myself, if I choose to give up the "protection" of an expiring key for a particular application I should be allowed to. Ditto on the permissions granularity. Standard groupings are awesome, but we absolutely need an "advanced" view. A simple default view should be sufficient for most casual users needs and will still prevent people from getting too confused.
Golden Gnu Gallente The Golden Gnu Corp	Posted - 2011.01.30 14:27:00 - [50] I would like to be able to link directly to the page that creates the VerificationCode with the pre-select security groups. User case: A user start jEveAssets for the first time and is asked to enter the keyID and VerificationCode. A link is provide to create the VerificationCode. User opens the link and just have to give the VerificationCode a name. The VerificationCode is auto generated The Security Groups needed to fully use jEveAssets is already select (Maybe highlighted in red, so user can see it's change by the link) User just have to click OK. and copy 'n' paste the information into jEveAssets IMHO It would simplify everything... _________________ Download is the meaning of life, upload is the meaning of intelligent life EVE.NiKR.NET - home of jEveAssets

TorTorden Amarr	Posted - 2011.01.30 14:54:00 - [51] Edited by: TorTorden on 30/01/2011 14:54:40 +1 on non expiring keys +1 on needing an account identifier or this will be ccp's stealth boost to corporate spies. +1 to allowing us 3rd party guys to abstract the end user experience. And in my personal experience just asking people for a limited api isn't entirely unproblematic, not from their trust point of view, its more that people keep sending me either the userid or the apikey and hardly ever both at the same time :S So adding user complexity to it might just be to much for some non super users. I'm in no way saying don't do it, I love it. but let us for example from a corp management point, set a list of API features we as corp would like access to and tie this in with the corp application process itself, I'e they apply to my corp and gets notified of that we need access to api x,y,z. The access key is made from within game according to our whises and they can apply a name to it and have the key data concatenated into the application itself. ------------------------------------------------ There is no such thing as good or evil. Just an egotistic struggle for self empowerment. ------------------------------------------------
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2011.01.30 15:37:00 - [52] Originally by: Ix Forres (I don't really care, I don't write apps any more, but if I were writing apps this would be a major facepalm moment. Moving in the right direction, but using a pogo stick to hop up the hillside when you could just walk...) You know CCP likes home-grown half-baked stuff, but that seems to be more a company policy than the fault of the devs actually doing it. At least I can't imagine they all really want to reinvent the wheel each time and fail to make it round. --
Gavri'el	Posted - 2011.01.30 15:55:00 - [53] 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 My thoughts exactly. I would actually work in another option, which would be to "tweak" the actual API access response. What I mean is this. Suppose: a corp is requesting your API's access to verify your application to that corp. You want to give access only for THAT character, and as well you don't wanna give access to your wallet size or transactions, but you do want to show BPO ownership, as well as employement history and char ownership history; you want to see all your API's content for an account in a mobile phone app; you want to give API access to a specific app, but want to minimize overhead. What could be done is install a set of (let's say) checkboxes, from the API management screen inside the Eve Gate, which gives a particular key a particular validity, in the same sense as what has already been done - Corp key, Char Key, etc., but with more control. This gives the player much more control AND a better understanding of the info given out thru his API key. Also of great importance would be to integrate to the gate an API validator tool, with which to test what is given out to each key holder. So here's a run-thru of what it would be like to access the API. You want to apply to a corp. Corp requires API access to BPO ownership and some generic info. You go to the EveGate and access the API management page; there you create a new API Key, name it, and check "BPO Ownership" and "Generic Info", and "Allow access to director role only" (for example). The rest remains unchecked. You send the API key to the corp. Corp wants to review your info, the director requests access through (for example) EveMon. The request is passed from EveMon to the API, you receive an EveMail saying you have an API access request pending. Go to the management page, and review WHO is asking for access. If verification is passed, click "Activate access". The requester of the access receives an EveMail saying access is granted. The director can then access the API from EveMon. If the director passes on the API key to anyone, authentication is required again, ensuring the safety of the info. You can also validate "Oh yeah, this key also gives access to this and this" by going thru a drop-down menu, each pulling a request for each particular item or family of items and visually reporting it (this can easily be done thru a https form). Much more granular control, challenge-response access, required verification for the user (which means more involved participation). You can even open a notification system to the OUTSIDE of Eve, kind of like on iPhone-style apps. -- Gavri'el
Ms Michigan Gallente Aviation Professionals for EVE	Posted - 2011.01.30 18:53:00 - [54] WOW! Awesome Ideas CCP! Thanks for the great news/dev blog. One thing I thought was worthy of bumping though is CJ's idea below. Just a thought. 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
Dragonaire Caldari Corax. SOUL CARTEL	Posted - 2011.01.30 18:56:00 - [55] Ok in an attempt to keep this short I added a wiki page explaining how I see this being done that IMHO will work well. You can look at my proposal at http://code.google.com/p/yapeal/wiki/KeyManagementProposal I'd also like to add myself to the list asking for a non-time limited key option. We need an APIs add to tell us what access a key grants. We need an API that at least let us know how many characters they have on the same account and a way for they to grant others access to the list of them. Think accountCharacters with just character and corporation names and IDs not all the other stuff. I've thought for a while to many things have been being add to that one API instead of adding new ones that are simpler to make, parser, and manage. Off topic rant For all of you that think OAuth etc are such a great ideas you are really just a hack waiting to happen. The problem with it and any of the others like it is it's totally based only on WHAT YOU KNOW which means anyone else can intercept or figure that out then they become you and no one else can tell the difference online. Before I would trust any system like that with the stuff many people are doing now it would need to require something you have something as well i.e. a smart key. Then it takes something you know and something you have to access it. Is something like that overkill for use with an online game account? Yes it is. Is putting Your game account access, FaceBook account with all of your personal information, bank accounts, etc into a system based on just stuff you know that can be intercepted or figured out a stupid thing to do too? I think so but people do it every day then cry about it when they lose their whole life when someone breaks in because they picked a poor password or some programmer on a site you might not even use but has access to the OAuth system had a bug that dumped everyone's info to some remote hacker that then posted it all online for everyone to use. Not having a single point of failure and multiple sign-ins and passwords is still much better if used correctly. Rant off Hopefully everyone find my ideas useful and maybe some of you will have ideas to improve upon it which would be great the more the better so CCP has a wide range to choose from when making the final decision and we can work together with them in making the APIs and even Eve itself better for a change and not just b%ching about they not know what they are doing or how they did it wrong. -- Finds camping stations from the inside much* easier. Designer of Yapeal for Eve API.
Sverre Haakonson Gallente	Posted - 2011.01.30 19:34:00 - [56] Edited by: Sverre Haakonson on 30/01/2011 19:39:37 1) Instead of creating universal keys provide us with a mechanism to combine a data source key (player) with a data sink key (CEO, evemon etc) to preventing usage of a player key from non authorized partys, so the player is able to check the data sink key at eve gate. If such a key is leaking by giving thr data sink key away, it's traceable. 2) Don't allow the use of password like keys. That don't work at all. 3) As a option it should be possible to give a key a longer livetime than 1 year.
Lennvas	Posted - 2011.01.30 20:23:00 - [57] The parts I understood sounded really good. As a non developing enduser I would like to get a notice in advance before a key is about to deplete, most probably via evegate, but perhaps evegate could transfer the notice to a user submitted emailadress. Or make it possible for applications to track the time left for the submitted api key so they are able to send out the notice themself.
Laechyd Eldgorn Caldari Certified Household Sweeping Consulting	Posted - 2011.01.30 21:39:00 - [58] If I understood this right we can now make separate API keys which give access to only certain things. I can see there's 2 very popular uses: 1) killboard (combat log) 2) skill status (for checking skills out of game) Please can you make sure keys for making these things work will not confuse users to give any other additional information and they will be easily configured. Ideally I'd guess there should be predefined settings for these. kthx.
Random Womble Minmatar Emo Rangers Electric Monkey Overlords	Posted - 2011.01.30 22:41:00 - [59] As someone that has got a large number of api keys registered in both evemon and EFT because corp mates or friends often look to me for setups and sometimes even training advice i cannot agree with the yearly limit. On ops and other events i also will have a hand sometimes in suggesting an appropriate ship type or lending a spare ship i own and having those details easily reachable without needing to ask each time makes everything easier. I doubt the people involved would want to have to send me a new key each year even if it is only once a year its still an annoyance. From a personal perspective alone with my multiple accounts the idea of a fixed yearly limit annoys me i dont want to have to update when i dont really need to.
Qoi Exert Force	Posted - 2011.01.30 23:52:00 - [60] For everyone still thinking EVE Gate is a social network (Maybe you should read the About page), it is a lot more than that. It's just the new name for the eve website and all the services it is going to provide (Account Management, Forums, SocialNetwork-WhatAmIDoingRightNow-Box, News, Calendar, EVEMail) etc. Having the API Management part of EVE Gate doesn't mean it will be "insecure" or have "insecure default settings" on a level with Facebook. Replace "EVE Gate" with "new version of eveonline website" if you still think eve gate is "spacebook".

Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2011.01.31 00:24:00 - [61] Originally by: Qoi For everyone still thinking EVE Gate is a social network (Maybe you should read the About page), it is a lot more than that. It's just the new name for the eve website and all the services it is going to provide (Account Management, Forums, SocialNetwork-WhatAmIDoingRightNow-Box, News, Calendar, EVEMail) etc. Having the API Management part of EVE Gate doesn't mean it will be "insecure" or have "insecure default settings" on a level with Facebook. Replace "EVE Gate" with "new version of eveonline website" if you still think eve gate is "spacebook". Erm, we don't really care what EVE Gate is, but the fact remains that EVE Gate "forgets" security settings every other patch. So statistically the likelyhood of API or account security being compromised rises exponentially by integrating it into the badly administered EVE Gate service. --
Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.01.31 03:01:00 - [62] Originally by: Catari Taga Originally by: Qoi For everyone still thinking EVE Gate is a social network (Maybe you should read the About page), it is a lot more than that. It's just the new name for the eve website and all the services it is going to provide (Account Management, Forums, SocialNetwork-WhatAmIDoingRightNow-Box, News, Calendar, EVEMail) etc. Having the API Management part of EVE Gate doesn't mean it will be "insecure" or have "insecure default settings" on a level with Facebook. Replace "EVE Gate" with "new version of eveonline website" if you still think eve gate is "spacebook". Erm, we don't really care what EVE Gate is, but the fact remains that EVE Gate "forgets" security settings every other patch. So statistically the likelyhood of API or account security being compromised rises exponentially by integrating it into the badly administered EVE Gate service. Plus its slow POS-Tracker 3.0 Hosting
Bhattran	Posted - 2011.01.31 04:11:00 - [63] I was excited as I read the devblog for empowering the user until I came upon: Quote: How will this affect the API key generation and the end-user? Greatly! The new API keys will be managed through EVE Gate. Oh joy. Originally by: Catari Taga Originally by: Qoi For everyone still thinking EVE Gate is a social network (Maybe you should read the About page), it is a lot more than that. It's just the new name for the eve website and all the services it is going to provide (Account Management, Forums, SocialNetwork-WhatAmIDoingRightNow-Box, News, Calendar, EVEMail) etc. Having the API Management part of EVE Gate doesn't mean it will be "insecure" or have "insecure default settings" on a level with Facebook. Replace "EVE Gate" with "new version of eveonline website" if you still think eve gate is "spacebook". Erm, we don't really care what EVE Gate is, but the fact remains that EVE Gate "forgets" security settings every other patch. So statistically the likelyhood of API or account security being compromised rises exponentially by integrating it into the badly administered EVE Gate service. ^This and CCP seems to not give a ** about it much like facebook. --WIS/Incarna/Ambulation where microtransactions come to play, and uh bars.--**
Wollari Phoenix Industries Black Star Alliance	Posted - 2011.01.31 13:19:00 - [64] EveGate / API / OAuth OAuth shouldn't replace API Possible use cases: Web Application requests access to user informations and redirect to EveGate with OAuth Call + requested access level User accepts authentifaction requests EveGate creates custom API Key (requestiong application + randomKey) so user can identifies the key User gets returned to the initial webpage with the custom API key in the OAuth response 3rd party application starts using the returned API key until the user revokes access (delete key) or key times out. User have the ability to revoke the custom API Key (that was created through OAuth) to revoke Access for particular web application API Keys should have a description field. Real Applications (like EveMon, EFT, etc) have problems implementing OAuth it would require a browser window inside the application that starts the OAuth challange and returns it back to the application. That can be a security risk when application starts sniffing the browser window input (phisining login, etc). So the good old API Key system should be prefered by Real Applications. OAuth for Webapps to exchange key informations. Expiration Dates on keys good for security in general it's a comming thing in business that licenses, certificates etc have an expiration date. Your 3rd party application that is secured with a trusted SSL cert have a life time of 1-2 years Your TS3 license is expiring aswell, etc other software licenses do this aswell Changing 1x per year your key shouldn't be a big issues (even if you've 5 accounts) Basically you should revoke your API key everytime you change your corp anyway, otherwise your enemy or former corp have access to your stuff. huge number of people don't care about their security and never change their api key ... Forcing API expiration just increases the overall api security and removes dead weight of the API Key database (api keys that are no longer valid can be removed) API Capabilites a new API call should return the capabilites of the api key. Then we don't need any more api calls to test the capabilites. Atm, we've to check account/Characters + account/AccountStatus to determe if it's a limited or a full api key. Without a Capabilites API, people will start requesting all possible API calls to determe the allowed features. Account Information Well ... i personally would like to see no account information (id, character list, etc) since it's only used for corp security and recruiting checks and basically replaces the ingame stuff Removing account information just turns out into exchanging screenhots again (which can be faked) or other details again. Should "character" keys return no account informations or just account informations with only 1 character listed? If somebody really wanna spy on you, they use alt-accounts anyway. Atm i think changes here have not the highest priority since we've other request that should have a higher priority (pointing to OAuth)
Sherksilver	Posted - 2011.01.31 14:12:00 - [65] Expire of Keys - Well, for the individual it might not be too bad (even with 5+ accounts). For the CEO that tracks a 200 man corp, that would suck big time. (even if only 1x per year). Question: Would one of the group options make it possible for a corp to let members see only the fuel levels of POS towers? (ie: a key they could use that would only show those particular items of the corp?)
Fade Toblack	Posted - 2011.01.31 14:21:00 - [66] On key expiry. It's not just a matter of the number of accounts you have, I use 3 different computers regularly and each has EveMon, EFT and EveMEEP installed on them. So that's 9 pieces of configuration for each account! Now I agree that in basis expiring keys is a good thing. But how about the option to extend a key - say for another 12 months. Allow a short period after key expiry during which a key can be resurrected if needed. Taking that to the next level, if it's no big deal to store keys permanently, having a bunch of different keys with pre-defined settings that I can enable for a couple of hours whenever I need them may be useful. On the grouping thing, I would suggest that's an interface issue - you should probably store preferences for all the calls. So why not have a expanding-out set of tickboxes, so if I tick the "Character sheet" group then the CharSheet and Standings API calls are ticked. Alternatively I can expand out the group and select them individually. Basically in the same way that most installers work when you select which components of a piece of software need installing.
Morast Kuiper Belt Industries	Posted - 2011.01.31 17:00:00 - [67] 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 I really like this. Which could allow the application to request what permissions it wants. Then the user only has to verify and allow the application to have those permissions. This would serve to reduce the complexity of users having to choose what permissions each key will have. It will also lock in a given key to a given application. CCP could also require a unique hash from each application, that would be part of the key. Which would really lock in the key to that application. Perhaps this is how CCP could allow unlimited time length keys. If a key is locked in to a specific application with a specific set of requested permissions. Then it could be considered a more secure key... regards Morast
Furious Joe	Posted - 2011.01.31 21:21:00 - [68] Edited by: Furious Joe on 31/01/2011 21:22:39 This is great stuff. And I agree with everyone else that we need unlimited keys, and we need a quick way for an application to send a user to EVE Gate with a pre-formed API key request. But if you're going to allow us to limit which alts are exposed by a key--which I fully support--then you've eliminated one of the main reasons for having so many accounts: Hiding alts from people I don't want to know about them. Consider: I have three EVE accounts, two of which have two characters on them. If I want to check on all my toons in EVE Gate--which will be more and more often as EVE Gate's feature list grows--I have to login three different times. But another way of describing my subscription situation is that I have five characters, and I'm paying CCP enough monthly fees to have three active skill queues, and run three simultaneous client sessions, although I rarely run more than two at a time. So why can't I have one single account, with one single point of entry, that I've paid to have authorized for five characters, three active skill queues, and two active client sessions? I don't know what the database implications are, but it would simplify API management, and it would allow EVE gate to be much more powerful by combining operations across multiple characters. For example, I'd like a unified email inbox across all my characters, and I'm sure there are a lot of multi-character reports we'd all like to have. CCP would lose some income from character transfers, but I'm sure they could figure out a way to make it up.
Draco Argen	Posted - 2011.02.01 02:00:00 - [69] Ok first off hurah for API advancement. In general all in the right direction. However two points I must raise. As a developer how will I detect that the user hasn't given me the access i need, and thearefore politely and infomratively telling them what they have/have not done and how to go about fixing this. Point two may circumvent one. Is managing multiple API sets starting from the Users POV going to be a complicated and confusing mess for your average user? Anyone who has tried to carefully manage permission sets under any major OS can attest to how much of a pita it can become. I can see 101 mistakes and confusion which will end in the user throwing the App in the bin and bringing out Excel / OpenOffice :s Wouldn't it be far better to take the Twitter approach and use OAuth or a similar concept. If done like this then the Application developer can request which ever Key set for itself (all the complicated gumph). EveGate etc can ask the user can the application called "Bills Eve Blogimy" access the following details? They say yes/no and can later revoke this access at their whim. aaand suddenly i see the problem with this idea (Thinking as i type here). The OAuth concept does not lend itself well to the concept of information verification or passing. e.g. Giving details for your corp recruitment interview, or verifying you possesion of T2BPOs etc. I really think there are two requirements here. Plain simple User wants App X to work. Secondly User wants to share and verify info about themselves in a limited manner. (Similar to how SSL certs work now, "via a trusted authority") I just really fear by facilitating the latter too much you will screw the prior innocent user and useful apps into the ground. Please at this early stage of development consider an OAuth style of augmentation to allow user friendly access to API data. It's so damn convenient for Twitter and easy to secure app by app. I think for the info verifying and sharing the proposed method is very good.
Seraphina Amaranth	Posted - 2011.02.01 11:32:00 - [70] So far we have Ix Forres (from eve-metrics) and Marcel Deveraux (Aura for Android) come out in support of OAuth instead of roll-your-own-keygen, and Wollari (dotlan) with some doubts. Ix, Marcel, how do you think an OAuth scheme would work?

Fade Toblack	Posted - 2011.02.01 13:40:00 - [71] You'll find the "fors" are the people running web sites which hook into the API and the "againsts" are people writing more traditional apps. Trying to hook either EveMon or EFT into the API as those apps exist now would be a major change to either app.
Matalino	Posted - 2011.02.01 15:25:00 - [72] Originally by: Draco Argen Wouldn't it be far better to take the Twitter approach and use OAuth or a similar concept. Bloody hell NO! Originally by: OAuth 1.The application uses oauth/request_token to obtain a request token from twitter.com. 2.The application directs the user to oauth/authorize on twitter.com. 3.After obtaining approval from the user, a prompt on twitter.com will display a 7 digit PIN. 4.The user is instructed to copy this PIN and return to the appliction. 5.The application will prompt the user to enter the PIN from step 4. 6.The application uses the PIN as the value for the oauth_verifier parameter in a call to oauth/access_token which will verify the PIN and exchange a request_token for an access_token. 7.Twitter will return an access_token for the application to generate subsequent OAuth signatures. Now factor in the requirements of recruiting... Originally by: OAuth 1.The recruiter uses oauth/request_token to obtain a request token from application. Repeat for each instance of each application used by the recruiter to filter recruits. 2.The recruiter directs the recruit to oauth/authorize on evegate.com. 3.After obtaining approval from the recruit, a prompt on evegate.com will display a 7 digit PIN. Repeat for each instance of each application: make sure that the recruit keeps the PIN paired with the applications. 4.The recruit is instructed to copy these PINs and return to the recruiter. Repeat for each instance of each application: make sure that the recruit keeps the PIN paired with the applications. 5.The recruiter is instructed to copy these PINs and return to the applications. Repeat for each instance of each application: make sure that the recruiter keeps the PIN paired with the applications. 6.The applications will prompt the recruiter to enter the PIN from step 4. Repeat for each application.Remember the recruiter needs to match the PINs to the applications based on information supplied by the recruit which may or may not include sufficient information depending on what is displayed to the recruit. 7.The application uses the PIN as the value for the oauth_verifier parameter in a call to oauth/access_token which will verify the PIN and exchange a request_token for an access_token. 8. The recruit must remember which application instances are his and which ones belong to the corp. Keys are multiplied by the number of applications and the number of instances of those applications. 9. If corp management adds another instance of an application (ie corp leadership changes and the access needs to be granted to new instances of the applications) then the process must be repeated again by each corp member for each new corp leader. 10. Repeat all of this each time that access keys expire. Originally by: New API Key System 1. The recruiter instructs the user to create an access key (or possibly a small number of access keys) on EveGate with access requirements specified. 2. The recruit copies the key(s) and sends them to the recruiter. 3. The recruiter enters the key(s) into any number of applications and forwards the key to corp/alliance leadership as needed. 4. The recruit/recruiter only needs to manage a small number of access keys. Originally by: Fade Toblack You'll find the "fors" are the people running web sites which hook into the API and the "againsts" are people writing more traditional apps. Trying to hook either EveMon or EFT into the API as those apps exist now would be a major change to either app. This is pretty much it! The OAuth model works okayish for players who will be giving access to a small number of website applications. For those using multiple copies of traditional applications it would be a total nightmare.
Tiruriku	Posted - 2011.02.01 15:33:00 - [73] Really only two things I personally would love 1. As others have mentioned, no mandatory lifetime maximum. Let me create a full access lifetime key that I can use for EVEMon and other tools. That isn't the key I'll give out to others but it will make my life a lot easier 2. Instead of logging in with your eve account how about creating EVE-Gate accounts not bound to a particular EVE membership that would let you aggregate multiple memberships? Many players use multiple accounts and it would be great to just log in once and link all my accounts so I could view all my mails, all my access keys and everything else with a single sign on. Logging out and in 5 times to check my subscriptions, for example, is fairly annoying. The gmail model works well here where I have 1 gmail account but can send/receive email from a dozen separate addresses
Wollari Phoenix Industries Black Star Alliance	Posted - 2011.02.01 23:50:00 - [74] Edited by: Wollari on 01/02/2011 23:51:05 Originally by: Matalino Originally by: Draco Argen Wouldn't it be far better to take the Twitter approach and use OAuth or a similar concept. Bloody hell NO! [...] This is pretty much it! The OAuth model works okayish for players who will be giving access to a small number of website applications. For those using multiple copies of traditional applications it would be a total nightmare. Don't paint everything black right now. My approach would be that the OAuth should just be a system to generate an application specific api key (or in OAuth terms access_token) for the requesting webpage. After that key exchange the webpage has it's own API key and people can work like they've usually do. If you don't like OAuth you you'Ve still the possibility to enter your API key manually. For the Recruiter it's basically easy: a) Either the applicant provides the a custom generated API key (old fashioned way, which requires a lot of clicking and lots of tools) or b) The Recruiter says: Please put up a application on our corporation webpage and provide access to your api key. After that we'll review your application (in the corporate intranet system) and make our decision. OAuth should just be on top for (normal) API Key exchange. It should not replace the API System in general. It's like Facebook with their GraphAPI. After the authentication process, you've the GraphAPI where you can query user data until he revokes your application/accesstoken/apikey.
Lord Matrix Flying Banana Squad	Posted - 2011.02.02 15:22:00 - [75] Just a few things that weren't mentioned: - Please use server side caching (Memcached, Redis, ...) of API replies instead of imposing a limit of 1 request per hour (seriously, wtf?). - Please provide API replies in JSON format. It is much more lightweight, less verbose and a lot easier to work with. - HTTPS is useless if the client doesn't check the certificate against a CA. Otherwise, any MITM can get the secret keys by faking a certificate, while still giving the victim a false sense of security. In my prediction, none of the client API libraries will check the validity of the certificate. Therefore, I'd like you to provide official or semi-official (created by community but validated by you) libraries for the most popular languages used (PHP is a good example) that check the validity of the certificate. 3/4 pure lunatic, 1/4 absolute genius
Swynet	Posted - 2011.02.02 18:37:00 - [76] Well has it seems right now the idea of being abble to chose different setups for different purposes seems more flexible than actual system. I'll reconsider the option of giving someone the informations about my char knowing that he will know only what I want to and no more witch colour boxer I use after every shower Now if has potential member I see positive changes, i'm not blind or fool enough to think that the paranoid mind side of the game asking people what they eat and at what time will change, because this parameter is a human one, the one coming from the corp/alliance managers witch seem the one you guys can't do anything to make them change their minds, has we can already see in some posts. You can tell them to take some pils but I don't think those ones are ready to reconsider their absolute paranoia, tell a fool that he's one and you are wasting your time
Mahipu'ali	Posted - 2011.02.03 14:56:00 - [77] Any player who is not concerned with security deserves to have their account hacked and their toon & assets sold/stolen. That said, security management still needs to be 'simple' for players. Keys should have mandatory life limits - so link the key time limit to the account payment limit, i.e. you pay for another 30 days of account it automatically extends your key limits by 30 days - OBTW that means key life limits are (for most players) 30 days max - not 1 year Totally agree that key management should be part of account management - not on EVE Gate.
SunMoonStars Amarr Standards and Practices	Posted - 2011.02.03 20:33:00 - [78] Originally by: Dragonaire ... We need an API that at least let us know how many characters they have on the same account ... I fully understand why there are multiple requests for this. And I totally and strongly disagree. All in-game interactions are on a Pilot basis. Each pilot/character is a discrete entity. There is no proper reason to expose RL information, ie., other pilots on the account, through any in-game or API mechanism. And even the legacy reason for this request is invalidated by the use of multiple accounts. Unless someone wants to argue for API access to all accounts held by a person? Yes, this change makes life more difficult for Corp Security personnel. But it is a superior pure game mechanism to not expose all the pilots on an account. Adapt or die.
Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.02.03 22:39:00 - [79] Originally by: SunMoonStars Edited by: SunMoonStars on 03/02/2011 20:40:10 Originally by: Dragonaire ... We need an API that at least let us know how many characters they have on the same account ... I fully understand why there are multiple requests for this. And I totally and strongly disagree. All in-game interactions are on a Pilot basis. Each pilot/character is a discrete entity. There is no proper reason to expose RL information, ie., other pilots on the account, through any in-game or API mechanism. And even the legacy reason for this request is invalidated by the use of multiple accounts. Unless someone wants to argue for API access to discover/identify all accounts held by a person? Yes, this change makes life more difficult for Corp Security personnel. But it is a superior pure game mechanism to not expose all the pilots on an account. Adapt or die. Have to at least have it as an option to give out, or else corps/alliances will start asking for screenshots of character selections again. If its an option, then its your choice if you want to join a corp/alliance that ask for it. POS-Tracker 3.0 Hosting
Zagdul Gallente Shadowed Command Fatal Ascension	Posted - 2011.02.04 11:39:00 - [80] First off, this is great! Thanks for the update. I have a couple requests and not sure if it's been mentioned... I'm in a hurry and don't have time to read through all of this. 1. No expiration on the API option. 2. When the API is generated, can requests within the key be already defined... I think this will help your servers. For example: USERID_APINUMBERS_ISMAILALLOWEDYN_ISWALLETALLOWEDYN_ISSKILLSALLOWEDYN etc... If you put the allowed API returns right into the key, requests to your servers will become less frequent and they may run smoothly as the applications written which check will do that locally. That is all thank you for reading.

Hel O'Ween Men On A Mission	Posted - 2011.02.04 15:43:00 - [81] Edited by: Hel O''Ween on 04/02/2011 15:43:18 Originally by: Catari Taga Erm, we don't really care what EVE Gate is Well, I do - a lot. It's ****Book in space ... remember: if it walks like a duck and quacks like a duck, it's most likely a duck. API keys in spacebook? Time to stop development for me, it seems. -- EVEWalletAware - an offline wallet manager
Li Poe	Posted - 2011.02.04 19:54:00 - [82] This set of proposed changes looks very good. Limiting what a 3rd party site requires to function greatly reduces the risk surface that a 3rd party site might present to my game data. For example, SQL injection attacks against a poorly developed site that holds full keys would be a huge security hole presented by a 3rd party application. A 3rd party site is much more likely to be insecure because of a lack of adherence to OWASP standards, etc. I have avoided joining KBs for that reason. Nice to see you guys thinking in these terms. Thanks!
Shiu Juan Gallente Eve University	Posted - 2011.02.07 22:51:00 - [83] Originally by: TornSoul Edited by: TornSoul on 29/01/2011 19:52:50 "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". I wasn't totally clear on whether the Originally by: "CCP Prism X" The edit functionality will then allow you to change all of the above with the exception of the keyID itself. You can always delete keys and recreate them for a new keyID if you believe it is somehow compromised. In order to reduce the risk of compromised keys we would advise you to always generate new keys, with an auto-generated verification code as well as a short lifespan, to hand out to second parties. meant that you could create a rough approximation key by selecting a few groups, and then when you go into Edit tick and untick specific pages in those selected groups. If not, that would be a nice thing to have. I really like this direction (more specificity of use, expiration, and granularity to one character.) I can think of an application (that I am today using a Full API key for) where I only need to share WalletTransactions, and not WalletJournal. However, I definitely don't think it is worthwhile to make the granularity down to [CAN access WalletJournal.xml, CANNOT access WalletJournal.csv], unless this ends up being easier because the page URL is a key in an lookup table.
Epitrope The Citadel Manufacturing and Trade Corporation	Posted - 2011.02.07 23:54:00 - [84] This is fantastic news! On the subject of key expiration, I think a good balance between usability and security would be to have the option to extend a key's lifetime. If the player never uses it, and the keyholder never talks to the player, there's no reason the keyholder should be able to keep the key indefinitely. The key expiration date should be part of the key capabilities API, of course. I don't have a problem with having key management in EVE Gate. Parts of EVE Gate are designed for sharing, and apparently there have been problems with losing sharing settings and resetting to bad defaults. API key management wouldn't ever be designed that way. As proof that security is being kept in mind during design, see the key expiration idea. I would like API-level permissions in addition to group-level permissions. Simplicity is good, but EVE has a lot of complexity, and security isn't necessarily the best thing to trade for simplicity. Plus, I would imagine that if the applications can request keys, there would be very little direct key generation or editing. As Stillman pointed out, there is an access log web page, but I think what people are asking for (and what I'm asking for!) is an API version of it. If one already exists and I just don't know about it, please enlighten me! Applications should be able to request a key, not just have one given to them. As Ix pointed out, the application should be able to say "these are the calls I need to work" and "these are the calls that would enable optional functionality". It would be nice if applications could organize API calls into features, sort of like custom groups, which could be selected or deselected as a whole. It wouldn't be very useful, for example, to grant permission to use the mail bodies API call but not the mail headers call. I'd imagined an application being able to request a key with only a character name; although this presents the potential for spam, rate limiting and having a maximum pending key request queue size should make it reasonable. OAuth might be one way to do that, but I'm weakly against it in this instance. It seems to me to be needless complexity, an external dependency for application writers, and to not gain much for all of that. I haven't heard many arguments in favor of OAuth beyond "avoid Not Invented Here syndrome!" It's probably my understand of OAuth is incomplete; what am I missing? I'm very much in favor of character-only keys. There are use cases for knowing what characters are on an account, such as for skill monitors to only complain when none of those characters are training. Recruiting has always seemed very invasive to me, however, and if it will be possible to see what characters are on an account, that API call should be optional and not the default. Privacy is more important to me than recruiters' convenience. These are exciting times for the API. Go Prism X and Stillman!
KaarBaak Minmatar The Mighty 13th	Posted - 2011.02.08 18:44:00 - [85] Would a compromise on the key expiration be having the keys "go inactive" after a set period? After one-year, the key goes inactive and it simply requires the user to go in and check/uncheck the "active" box of an existing key. Circumstances rule men; men do not rule circumstances. --Herodotus, Histories
Taureau Innovia Innovia Alliance	Posted - 2011.02.11 03:51:00 - [86] Great, But... My alliances website ENTIRELY depends on this system, please don't make it too painful. If you're going to HIDE other characters, at least say how many are hidden (you don't even need to show the names). For example, if an account has 1 other character, just put in something as simple as an integer value... <hiddenchars>1</hiddenchars>. That way corporate executives can say "I need to see all the characters" and make the spy go back and show them their full key. You will NEED a feed or way to know what accesses each key allows. This can be a new feed with a series of tags with 1 or 0. This would also include being able to differentiate between a corporate and character key. This would also be a great improvement in general even to the current API system. Keep the process of creating keys SIMPLE, but at the same time make the separate process of modifying the keys very advanced and flexible. The main issue I have as a CEO is this is currently, the process of asking a recruit for their key is this... Recruiter: Hey, I need your API User ID & Key: http://eveonline.com/api Recruit: Limited or Full? Recruiter: Limited (or Full) Recruit: Okay, then they paste it. The dev blog shows the new process as this... Log into EVE Gate on a character on the account you want to link the key to (or the character in question for a single character only API) or, in the case of corporate keys, a character with the director role. Go to the API Key Management Select "Create New API Key" Give your key a name so you can easily differentiate between the purpose of keys in the management interface through a descriptive name. Select a lifespan (see Further Security Additions above) for your new key, the default will be six months. Select the type of key you are generating Corporation Key (Requires Director role) Account wide key Character bound key Assign call groups to your key. Auto-generate, or assign, a verification code to go with the keyID This worries me, I propose you make some sort of template keys. Also, an especially good idea would be a direct link to the API page, and attempting to make the new system just as easy on a recruiter, IE make the 2nd list more like the 1st list while keeping the things from the new list. Please keep in mind that web applications also use the API. My alliances website 100% relies on them. So I hope you keep to your work of slowly transitioning and keeping both versions of the API key system online for a short time. On the other hand, the lifetime thing is good for CCP's database & key security. It also requires you'd need something to re-validate or replace expired API keys on your app, but that's probably needed anyway (at least with my app). Believe it or not, I've held back a lot of thoughts on this matter and a lot of my programming gripes.
Dragonaire Caldari Corax. SOUL CARTEL	Posted - 2011.02.11 15:04:00 - [87] I'll assume my proposal got lost on the first page after the whole Oauth debate so now that it's died down I post it again for those that don't want to go back and find it. http://code.google.com/p/yapeal/wiki/KeyManagementProposal It address several of the more recent post about how to organize stuff to make adding APIs to the key very easy but still let power users dig down into the detail if they want. It also address the need for combined char/corp keys that would make them much easier to manage when both are needed. I'm sure there is some room for improvements in it but it is based on a know working system that I've guided many senor citizens through using over the phone at work so I think most Eve players should find it a breeze to use Like to hear some feedback or suggestions for improvement and I'll update it with any that everyone seem to think are good. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.

CCP Prism X Gallente C C P C C P Alliance	Posted - 2011.02.14 16:26:00 - [88] Sup! Just thought I'd pop by so nobody thinks I'm ignoring the comments and give a bit of feedback back! oAuth, challenge/respond and other methods.. Not happening. I doubt you'll be able to convince us that there's more gain than pain. This is already a rather extensive overhaul of the current infrastructure and I simply do not see oAuth maximizing total happiness any more than improving on the already known access schema. Eve Gate As mentioned already this is just a natural evolution of things. I'm not really understanding peoples security concerns with EVEGate as they seem to relate to decided defaults on character wall settings. That has nothing to do with the API and I can promise you that you will not start out with an default API key that everyone will have knowledge of which has access to everything. The idea of having a way of linking to Eve Gate with predefined key parameters is a pretty spiffy idea. I'll check with my Eve Gate resources if that is possible.. once they have time for me. Access Logs As Stillman mentioned these already exist. Having them in API call form is not a bad addition at all! Are corporation keys only creatable by directors? That was my original plan. However, there is nothing stopping us from allowing people to create corp keys according to their corporation roles and titles. I was thinking I'd want the directors to have full control over their corporate API keys and not have to worry about people with roles giving them out while they are sleeping. Perhaps I can get some more opinions on this? It's quite possible that I'm being overly paranoid on your behalf. Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this? Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful! Key Properties API Call This is clearly needed if only to query the access level of the api keys. This would also include stuff like the expiry date so that applications can warn about upcoming key expiry or websites send emails to people to remind them to give their expiry date a bump. This obviously depends on the final decision on the expiry date of keys. Also, this would be a good place to at least tell people whether the key was account bound or character bound, this could serve as a compromise for not being able to see the actual alt characters which I do not want to expose on keys that the user has specifically requested to be bound to a single pilot. How does that sound? Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? Could you suggest alternatives that do not involve immortal keys. I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it. Keep it coming! P.S. All statistics were made up on the spot! ~ CCP Prism X EVE Database Developer and Acting API Dude

Qoi Exert Force	Posted - 2011.02.14 17:26:00 - [89] Hide Alts: I'm not sure i understand you correctly. The /account/Characters API call should definitely stay for account keys. For character bound keys, this API call should not be available. Is that what you mean by "hiding alts"? Then i completely agree. Immortal Keys: I think the possibility to renew your key via evegate, so you don't have to communicate a new key to all api requesting parties is a very good compromise. Keep up the good work

CCP Prism X Gallente C C P C C P Alliance	Posted - 2011.02.14 17:31:00 - [90] Originally by: Qoi Hide Alts: I'm not sure i understand you correctly. The /account/Characters API call should definitely stay for account keys. For character bound keys, this API call should not be available. Is that what you mean by "hiding alts"? Then i completely agree. As I do not fully understand you: What I just proposed is that the /account/Characters call will be available but just show the character the key is bound to (making it useless for most things) but that the non-existant /somethingCauseAccountDoesntReallyFitProbablyAPIorSomethingElse/keyPropertiesOrSomeOtherName would tell you it was a character bound key rather than an account bound key. ~ CCP Prism X EVE Database Developer and Acting API Dude


Qoi Exert Force	Posted - 2011.02.14 17:38:00 - [91] Originally by: CCP Prism X As I do not fully understand you: What I just proposed is that the /account/Characters call will be available but just show the character the key is bound to (making it useless for most things) but that the non-existant /somethingCauseAccountDoesntReallyFitProbablyAPIorSomethingElse/keyPropertiesOrSomeOtherName would tell you it was a character bound key rather than an account bound key. As i do now fully understand you: Makes a lot of sense, and helped me (and hopefully others) to understand it. Btw, you have awesome hair. (Why isn't it pink?)

CCP Prism X Gallente C C P C C P Alliance	Posted - 2011.02.14 17:53:00 - [92] Edited by: CCP Prism X on 14/02/2011 17:52:59 Originally by: Qoi Originally by: CCP Prism X Btw, you have awesome hair. (Why isn't it pink?) Because most colouring agents leave a chemical residue in your hair that keeps it from properly locking up into dreads. ~ CCP Prism X EVE Database Developer and Acting API Dude

Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.02.15 02:27:00 - [93] Originally by: CCP Prism X oAuth, challenge/respond and other methods.. Not happening. I doubt you'll be able to convince us that there's more gain than pain. This is already a rather extensive overhaul of the current infrastructure and I simply do not see oAuth maximizing total happiness any more than improving on the already known access schema. I don't like the idea either :) Originally by: CCP Prism X Eve Gate As mentioned already this is just a natural evolution of things. I'm not really understanding peoples security concerns with EVEGate as they seem to relate to decided defaults on character wall settings. That has nothing to do with the API and I can promise you that you will not start out with an default API key that everyone will have knowledge of which has access to everything. the other issue with EVE Gate is that it tends to be a tad slow Originally by: CCP Prism X The idea of having a way of linking to Eve Gate with predefined key parameters is a pretty spiffy idea. I'll check with my Eve Gate resources if that is possible.. once they have time for me. Other then the EVE Gate part, that would rock. Originally by: CCP Prism X Are corporation keys only creatable by directors? That was my original plan. However, there is nothing stopping us from allowing people to create corp keys according to their corporation roles and titles. I was thinking I'd want the directors to have full control over their corporate API keys and not have to worry about people with roles giving them out while they are sleeping. Perhaps I can get some more opinions on this? It's quite possible that I'm being overly paranoid on your behalf. Roles for corp APIs? Originally by: CCP Prism X Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this? Let us decide if we want to restrict them or not, but also let the receiver know if it may be restricted or if it is a full picture. If corporations don't have the ability to get this infor through the api, they'll start asking for screenshots again, which is a risk to account security. Originally by: CCP Prism X Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful! This is a must. How I would do it is user selects group, it selects everyting in that group. If I want to expand that group, I can, and deselect something in that group. Kind of like a lot of software installs. So I could select Character Skills Group, which would select: Character Sheet, Skill Queue, and Skill in Training. But I don't think they should have Skill in Training, so I could expand the group, probably by clicking one of those little + signs in the box, and deselect Skill in Training. Originally by: CCP Prism X Key Properties API Call This is clearly needed if only to query the access level of the api keys. This would also include stuff like the expiry date so that applications can warn about upcoming key expiry or websites send emails to people to remind them to give their expiry date a bump. This obviously depends on the final decision on the expiry date of keys. Also, this would be a good place to at least tell people whether the key was account bound or character bound, this could serve as a compromise for not being able to see the actual alt characters which I do not want to expose on keys that the user has specifically requested to be bound to a single pilot. How does that sound? Exactly! Will save bandwidth, trouble with pointless errors. Character bound keys are probably all most apps need except when checking for recruitment purposes. Having account keys that list characters is what's needed for that. Plus, it means spies and theifs need multiple accounts, trying to keep your bonus in mind. (anyone who makes the api better should get one) POS-Tracker 3.0 Hosting
Johnathan Roark Caldari The Graduates Morsus Mihi	Posted - 2011.02.15 02:29:00 - [94] Originally by: CCP Prism X Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? Could you suggest alternatives that do not involve immortal keys. I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it. I actually like this idea. And cobined with the Key Properties with when the key expires, shouldn't be a huge deal. I'd go longer then a year though, maybe two. Suggestion for the templates: How about a preformed url: https://api.eveonline.com/requestKey.aspx?scope=account&lenth=1year&calls=AccountStatus,Characters,AccountBalance,CharacterSheet,ContactList,IndustryJobs,KillLog,Research,SkillInTraining,SkillQueue,Standings,WalletJournal,WalletTransactions&key=randomstringhere They go to a page with everything preselected, they can add things (pointless if the app doesn't use it), take thigns out, and change the length of when it expires. The user then can say approve or decline. If it was sent with a referal, redirect the user back to the website they came from with accept or decline, changes made, and the key pair. User doesn't have to select what they want to give the website/app as long as they are ok with the permissions they are granting, no copying and pasting. POS-Tracker 3.0 Hosting
Dragonaire Caldari Corax. Everto Rex Regis	Posted - 2011.02.15 02:54:00 - [95] Here a few replies for you CCP Prism X Eve Gate Team working on it has at least twice screwed up simple security stuff by resetting permissions. Why would we think they would be any better in the future? They shot themselves in the foot on this one more than once and it will take a long time for most developers or even normal Eve players to believe in them again. Even if they don't mess up the key stuff itself if they reset stuff so some one can get in to add one does it matter? Since it's mostly a social site IMHO and I think most other developers view it that way as well that means it has a very large targeting X on it from hackers, social engineers, etc and adding the API stuff to it just makes the pay off that much bigger. The main Eve site has an X on it too but it's much smaller. You yourself remarked in your post on how hard it is to get any of them to take time out to talk with you so where are they going to find time to actually do anything for the API? You may have been just joking but I'm betting you thought of it because it's actual happened before to you or others. Are corporation keys only creatable by directors? I think they should have the same access in or out of game. Either you trust them with both or you don't and shouldn't be giving them the access. Why trust them with the data in game and not out they can always just copy and paste the data out any way or probably find it in the cache as well so having it available from the APIs doesn't really change anything. Exposing alts! Someone else floated the idea to have it say how many other characters exist on the account. That would be enough by default but any less will have recruiters asking again for screen shot etc and would be a regression. Outside of recruiting most things don't care and just knowing there are other characters should be more than enough. (Think promos for multiple char discounting for applications, etc for why it would be good thing). I can tell from the Blog and your comments you have the idea that the user/account can go away entirely but as long as people can only have a set number of characters per etc you're not going to be able to do that as that is how everyone views things and even if things were changed so there wasn't those limits like we have now everyone is still going to view it as a person with their account and will want to have an API system that reflects that. Granularity of customization Once again if you don't think they'll have time to do it right why is it a good idea to move this over to EveGate? If you haven't took the time to read through my idea yet I linked in please do and have someone from web development have a look too as it show a very easy to develop and use system to let people have the level of control they want. With the addition where applications can direct players to the site and have preset templates or a way for them to preselect APIs it would make it very player as well as third party developer friendly. Also corporations and/or alliances can put out lists of what APIs their members should/shouldn't be giving out to third parties if they decide to for security etc. Key Properties API Call Simple this has been needed for a long time and the changes being looked at just make the case for it much stronger. Key Expiry So every year everyone is going to have to renew keys for all of their characters they use for EveMon on their own computers and other local applications? There is a need for infinite keys but it probably shouldn't be the default and an extra "Are you sure?" prompt wouldn't be out of line but not having it as an option once again would be a regression since the current keys work that way. That about covers everything and I'm out of room in this post anyway -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.

CCP Prism X Gallente C C P C C P Alliance	Posted - 2011.02.15 08:38:00 - [96] I never meant to imply it was hard to get the EVE Gate team to do anything for me. I'd never talk down to my coworkers on a public forum. That would not be professional. Fact is we have to manage our resources on all fronts and they are actually the team I have the best access too on account of having the same producer as the API. However, that is not the only reason for the move. It's a very natural choice in all regards as others have commented on before. I understand people were not happy about the default privacy settings. But I do not understand how that makes the EVE Gate authentication any less secure than your client or eveonline.com authentication. ~ CCP Prism X EVE Database Developer and Acting API Dude

Wollari Phoenix Industries	Posted - 2011.02.15 10:28:00 - [97] key expiry I think PrismX's idea to bump/refresh an existing key is a great thing for all. On the one hand you've keys that are expiring after a (half) year for security reasons, and on the other people just have to refresh their keys in the API management (if bump/refresh means to just extend the lifetime without changing the api key). oAuth Sad thing with oAuth but understandable in regards on work that is needed. I never wanted oAuth to replace the api, it would just simplify the key exchange between a webpage/application and the user. The rest is done via default API. Just keep in mind, if you ever think about extending eve gate via 3rd applications like facebook, it's nearly a must have for key/auth exchange. But I doubt that will happen anytime soon (looking on work priorities, goals and roadmaps). corp api keys I think corp keys should only be created by directors. If members really need API access to corporation assets, transactions, pos informations, etc they can ask a director that he'll create a special key for you, if they feel the need for it.
manasi Caldari Ceptacemia Petition This	Posted - 2011.02.15 14:19:00 - [98] CCP prism all the debate around alt's begs a question. How exactly would Alliance or Corp leadership know if a player is not telling us the truth about alts if they are not discoverable via API's? It is Currently exceedingly easy to NOT tell people about your alts, yet via limited API, CCP provide a small layer of verification "this pilot is who he says he is" and the decision about alts is left up to us. If we wish to find out who they are, that information is currently available( alts on the same account) . There is a check as a pilot that does not supply his /her API can be called a security risk. There are also plenty of alts on separate accounts that can circumvent this check. SO an existing game mechanic already allows for spies etc to infiltrate. In addition for Corps/ Alliance to have a semblance of corp/alliance security If you remove the ability for background checks to show the alts of a character, how exactly will we recruit pilots? How will they prove to the recruiter they have no alts in other corps? They won't is the answer. This removal of showing alts to people perpetuates this idea, if not encourages it. Why not give Corps/Alliances a way to verify pilots (such as it exists now)? As a recruiter and responsible for ferreting out spy's in my old alliance this job was made difficult enough already , you really want it to become even more difficult? As it is the ONLY tool available via CCP is alts on the same account... If you take away THAT single tool what else is left? Trust? Please now get a grip... Is this to make the large alliances slim down? Is this an attempt to further drive large alliances away from recruiting large corps? What is the point of removing the ability to check alts on the same account?
Xhae	Posted - 2011.02.15 15:18:00 - [99] Edited by: Xhae on 15/02/2011 15:24:59 Edited by: Xhae on 15/02/2011 15:21:40 Originally by: manasi If you remove the ability for background checks to show the alts of a character, how exactly will we recruit pilots? <snip /> What is the point of removing the ability to check alts on the same account? I think you're reading too much into the announcement that players will be able to create 'Pilot Keys' showing only a single pilot. CCP PrismX has stated that Account Keys will continue to be available, and that there will be an API query to discover which kind of key you have been given. Simply require an Account Key for verification of all the account's pilots.
Oraclegol Caldari Beasts of Burden	Posted - 2011.02.15 15:25:00 - [100] Why should you care about what alts the person has. This will have no impact on large spy "rings" for the following reasons. 1) this will never effect real spies with 3 different acounts 2) Spies are part of the game good or bad , next you will be requiring people to post there passport's with there char to check for spies 3) With the character bazzar. it is dead easy for a spy to get a new alt.After they have submitted there api info, they simply transfer a char over to there account. The api is not a very good way to catch spy's it is blunt and ineffective, and only really has limited implications for meta gaming.

Dierdra Vaal Caldari EVE University Ivy League	Posted - 2011.02.15 15:26:00 - [101] Edited by: Dierdra Vaal on 15/02/2011 15:27:03 Some information about the characters on an account (number of characters, their names/corp/alliance, etc) should remain visible through the API. If you hide this, it will just mean corps will once again require people to submit screenshots of their account which is worse from an account security perspective. I realise it may seem 'immersion breaking' or 'metagaming encouraging' but the truth is that due to Eve Online's harsh reality this sort of security is required for corps. And in that case, the API is the most user friendly and secure way to do it. On behalf of all recruiters everywhere: please dont remove that functionality. * * * Director of Education :: EVE University * * * CSM1 delegate, CSM3 chairman and CSM5 vice-chairman
Oraclegol Caldari Beasts of Burden	Posted - 2011.02.15 15:36:00 - [102] If you were to go to screen shot's what is stopping from photoshopping a fake login screen or better yet making an program that dynamic makes the login screen * pull's the pic * and add's all the dynamic stuff (such as news)
Jessica Verne Minute to Midnight	Posted - 2011.02.15 23:28:00 - [103] Edited by: Jessica Verne on 15/02/2011 23:32:54 Anyone else notice how when the subject comes up, T2 BPOs are no big deal, yet in the examples given the DEV Blog, verifying a character or corporation owned T2 Bpo/s was of great importance? Overall is sounds like a great idea moving forward, only wish I could get back the 2 months I spent implementing this granular functionality myself for my corp and alliance Also, I'll second (third?) the motion to have the ability to verify the scope and length of validity of the access code given, since without it we'd have to be pounding the api practically daily if its being used to enforce any kind of security measures. (Not that its that much better atm to be honest)
Catari Taga Centre Of Attention Middle of Nowhere	Posted - 2011.02.16 01:24:00 - [104] Most things have been said and I agree with what has been said. Specifically: Expiring API keys that can be refreshed by the user is actually ok from my perspective. The ability to send a predefined key string to EVE Gate requesting a specific API key so that the user does not have to check boxes and can just confirm should be a priority in my opinion. Other characters on the account must be available via an optional account bound key for recruitment purposes. Corp API for characters with roles: I am against. Just one example: A corp member may have starbase fuel technician role but only access to a specific POS. Via the API that player would get access to the fuel data for all POS, which may not be desired. I agree that a director could just create an additional key under the new system and give it out along with the role if so desired. --
Zhou Wuwang Federal Laboratories	Posted - 2011.02.16 07:09:00 - [105] Edited by: Zhou Wuwang on 16/02/2011 07:11:22 I very much appreciate and agree with these changes. However... Quote: For example, the character bound API contains 25 separate calls. 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 must disagree with this assumption. Making a key for each potential call is absolutely the way to go, because it defeats providing more data than required -- it is in keeping with the principle of least privilege or principle of minimal privilege. Anyone smart enough to handle Eve and use the API system is smart enough to handle assigning a key to a specific call.
Zhou Wuwang Federal Laboratories	Posted - 2011.02.16 07:28:00 - [106] Edited by: Zhou Wuwang on 16/02/2011 07:35:39 Originally by: CCP Prism X Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this? Provide the current corporation and alliance of the ALTs without the characters' names. It denies a recruiter the character history, but is a happy medium. The fact remains, any spy worth his salt is infiltrating on a separate account. The pre-occupation with checking alts on the same account is basically the dumb trying to expose the stupid. Want to end screen shots? ... then make it against the EULA and censure characters that demand screen shots.
Oraclegol Caldari Beasts of Burden	Posted - 2011.02.16 16:04:00 - [107] Originally by: Catari Taga Corp API for characters with roles: I am against. Just one example: A corp member may have starbase fuel technician role but only access to a specific POS. Via the API that player would get access to the fuel data for all POS, which may not be desired. I agree that a director could just create an additional key under the new system and give it out along with the role if so desired. From what i understood is that just because you had the roles does not mean you would be given the key's. rather the director could select the people , think of a new set of roles that would handle just api aka pos data manager (lame name i know) and that person would be able to pull the data.
Matalino	Posted - 2011.02.16 18:35:00 - [108] Originally by: CCP Prism X Just thought I'd pop by so nobody thinks I'm ignoring the comments and give a bit of feedback back! I was begining to wonder about that. Glad to know you are still reading. Originally by: CCP Prism X Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this? Key Properties API Call This is clearly needed if only to query the access level of the api keys. This would also include stuff like the expiry date so that applications can warn about upcoming key expiry or websites send emails to people to remind them to give their expiry date a bump. This obviously depends on the final decision on the expiry date of keys. Also, this would be a good place to at least tell people whether the key was account bound or character bound, this could serve as a compromise for not being able to see the actual alt characters which I do not want to expose on keys that the user has specifically requested to be bound to a single pilot. How does that sound? Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? Could you suggest alternatives that do not involve immortal keys. I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it. A suitable Key Properties API could form the foundation of a compromise for both issues. With hidden alts, there needs to be a mechanic to detirmine if alts might be hidden, but that does not need to reveal the identity of those alts. (As others have said, if the API does not provide this information, recruiters will start asking for screenshots again.) If the Key Properties API indicates that it is character bound and not account bound, then it is clear that the key does not reveal alts. If the key holder feels that he needs an account bound key, then he can take the matter up with the account owner. This leaves the matter of trust in much the same state as it is now (full verse limited keys) but with greater granularity. For Key Expiry, it would be acceptable to require a finite expiration on keys if the Key Properties API provided expiration information so that applications can prompt users to reset the expiration date. Again, this will only work if expired API key values are retained so that they can be reactivated without reasigning the key's value and permissions: extending a key's expiration should only take a couple of clicks. Maximum life of one year and default life of six months is reasonable with such a system in place.
Matalino	Posted - 2011.02.16 19:18:00 - [109] Originally by: CCP Prism X Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful! Twist some arms if you need to. Having an Advanced Access View is important. Having two layers of granularity allows the top layer to be much simipler than a single layer could be while still retaining a reasonable level of granularity. It doesn't need to be a seperate view: just have the groups as folders than expand to list the API's within them. Since you requested proposals on how to break it down, this is what I suggest for the current API's: Account Status account/AccountStatus.xml.aspx Character Information account/Characters.xml.aspx char/CharacterSheet.xml.aspx char/Medals.xml.aspx char/SkillInTraining.xml.aspx char/SkillQueue.xml.aspx char/Standings.xml.aspx eve/CharacterInfo.xml.aspx Character Contacts char/CalendarEventAttendees.xml.aspx char/ContactList.xml.aspx char/ContactNotifications.xml.aspx char/MailBodies.xml.aspx char/MailingLists.xml.aspx char/MailMessages.xml.aspx char/Notifications.xml.aspx char/NotificationTexts.xml.aspx char/UpcomingCalendarEvents.xml.aspx Character Assets char/AccountBalance.xml.aspx char/AssetList.xml.aspx char/IndustryJobs.xml.aspx char/MarketOrders.xml.aspx char/Research.xml.aspx char/WalletJournal.xml.aspx char/WalletTransactions.xml.aspx Character Combat char/FacWarStats.xml.aspx char/Killlog.xml.aspx Corporation Information corp/CorporationSheet.xml.aspx corp/Shareholders.xml.aspx corp/Standings.xml.aspx corp/ContactList.xml.aspx Corporation Membership corp/Medals.xml.aspx corp/MemberMedals.xml.aspx corp/MemberSecurity.xml.aspx corp/MemberSecurityLog.xml.aspx corp/MemberTracking.xml.aspx corp/Titles.xml.aspx Corporation Assets corp/AccountBalance.xml.aspx corp/AssetList.xml.aspx corp/ContainerLog.xml.aspx corp/IndustryJobs.xml.aspx corp/MarketOrders.xml.aspx corp/WalletJournal.xml.aspx corp/WalletTransactions.xml.aspx Corporation Combat corp/FacWarStats.xml.aspx corp/Killlog.xml.aspx Corporation POS/Outpost Status corp/OutpostList.xml.aspx corp/OutpostServiceDetail.xml.aspx corp/StarbaseDetail.xml.aspx corp/StarbaseList.xml.aspx This grouping assumes that we will have an Advanced Access View. If such a feature is not available: the Character/Corporation Assets groups would need to be split into Assets, Market, Wallet and Industry; the Character Contacts group would need to be split into Calendar, Contacts, Mail and Notifications; the Character Information group would need to be split into Character Skills and Character Information groups.
Siiee Recycled Heroes	Posted - 2011.02.21 01:09:00 - [110] Edited by: Siiee on 21/02/2011 01:09:20 Originally by: CCP Prism X Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? As long as I can refresh non-expired keys that definitely brings it down from "rage inducing" to "minor annoyance" Originally by: CCP Prism X I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it. Honestly I don't see that as a problem. API access is not an account security issue, but a privacy issue. When it comes to account security I very much understand stricter mandatory restrictions, especially as they have a direct manpower "cost" to CCP in regards to petitions and support. But As far as anything that the API would show "you give us the tools, and let us make what we will of them". Having strong access controls as an options is very good, but it's my data, I should be able to share it as much as I wish. If people always give out eternal keys mindlessly and are not auditing their access then they will reap the consequences for their choice. And I don't buy that anything that a "character level" API call would show is entirely meta-gaming (which I could understand wanting to restrict somewhat) Assets and skills and orders and whatnot all just provide a verifiable paper trail. That API access could easily be offered as an in game service and would not be immersion breaking (think public certs). So don't try to protect me from myself, give me the tools and then let the consequences play out as they will. And honestly if it does get people to start thinking a bit about the security of their data on their own then you're only doing the world a service by providing a place where people can get a very practical taste of the importance of security without any real-world consequences. Originally by: CCP Prism X I understand people were not happy about the default privacy settings. But I do not understand how that makes the EVE Gate authentication any less secure than your client or eveonline.com authentication. The privacy issue leaves a very bad taste in people mouths. That taste will flavor everything that that team does for a long time coming, justified or not. Honestly I would hope that the whole issue would show those people who are in charge of those decisions how personal the topic is, and how important even very small issues people have with it are. But I also think that those people are so lost in their own "social" universe that I don't expect to see a change in attitude from them. Regardless of any technical issues, I don't' "trust" the decision makers involved, and that will color every feature that gets rolled into an eve gate exclusive, just by association. It's a silly issue, but one of perception, not logic.

ion Utama	Posted - 2011.02.24 11:20:00 - [111] api = you saying hack my acc into
Abramul Gallente StarFleet Enterprises -Mostly Harmless-	Posted - 2011.02.25 22:32:00 - [112] First, regarding key expiration: I would suggest including a prompt on the login screen or character sheet if any keys are almost timed out. Personally I'd favor just having number of included categories, last query time, and a button to renew, but you may wish to link the user to the relevant Gate page. Second, implicit keys: It should be possible for a character to set acces for certain groups of players without having to manually distribute keys. Logical categories are superiors, subordinates, corp/alliance members, recruiters with whom you have an active application, and contacts with good/bad standings. Third, Gate/game integration: If you're planning on moving more and more stuff onto the Gate, I would suggest that players have the option (off by default) of automatically logging in when they load the Eve Gate on the in-game browser.
Sasha Citrine	Posted - 2011.02.27 04:03:00 - [113] Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking
Abramul Gallente StarFleet Enterprises -Mostly Harmless-	Posted - 2011.02.27 14:10:00 - [114] Originally by: Sasha Citrine Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking Another option would be to include month of account creation and total skillpoints on the account; This would, at least, tell you if the character is an alt or if it's an account that's far older than the main. Maybe include number of transferred/reprocessed characters, too.
Matalino	Posted - 2011.03.02 17:11:00 - [115] Originally by: Sasha Citrine Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking As has been noted, this is a non-issue if the API meta-data states if a key provides access to all characters or only a selected character. If a recruiter is given a key that only provides access to a single character, he can sort that out with the recruit. This is no different than asking for an API key under the current system. Recruiters need to have their own policies for handling recruits that do not provide suitable API keys. Originally by: Abramul Another option would be to include month of account creation and total skillpoints on the account; This would, at least, tell you if the character is an alt or if it's an account that's far older than the main. Maybe include number of transferred/reprocessed characters, too. The account status API already provides the account creation date. It is up to the recruiter to deal with recruits that do not provide an API key that grants access to the API's requested by the recruiter.
Chibisuke Gallente Children of Avalon	Posted - 2011.03.04 07:41:00 - [116] Would you guys mind to also add an api that tells you which access a key got? I'd not like to have to query through multiple APIs and do testcalls just to figure out which apis I'm allowed to query with a accesskey.
Chromoburst	Posted - 2011.03.23 16:19:00 - [117] yeah no expiration. I'll disable keys myself if I need to. and although security is good, its not better for my users to have to go customize a specific key for my website because I need a unique group of api calls to provide my websites services and then have to do this each year. I dont want to deal with that mess as a coder. its not like anything in the API is sensitive enough to worry about. Make security simple for everyone.
Chromoburst	Posted - 2011.03.23 16:30:00 - [118] Quote: I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it. Let them yell. You dont prevent scams because people will fall for it, you dont prevent PVP cause people die. Its life, read the details if you dont want to get screwed over. They are going to yell no matter what. Give them the option (sand box sand box sand box) and let them handle the rest.
Aghlar Yardum	Posted - 2011.04.06 13:17:00 - [119] usually, you should opt for something like oAuth because: 1) it's a standard 2) it handles the concept of resource owners (characters) and resource consumers (apps or other users) 3) done properly, that will allow every user to consume other users resources (check status, check assets, etc...) if the users give permissions 4) it will allow CCP to stop the use of APIs for some applications if they desire to, without relying on concepts like IP (what about mobile devices, for instance?). 5) it's a standard and the specification is quite clear.
Meno Theaetetus Wildly Inappropriate Wildly Inappropriate.	Posted - 2011.05.11 05:03:00 - [120] Any chance of an update on this? Just a hint that its progressing as stated in the op would be great. I'm currently in the design phase of a project that this change will have a large effect on. A rough timeline for integration would be great, should I wait a few months or begin development based on the op?

Navarre Fuego	Posted - 2011.05.26 20:16:00 - [121] Regarding unlimited time keys, I think people are overreacting. When the renewal of a key is a single click on the API interface (probably on the API Home, where there would be a list of keys with a "Refresh" button on each line, however small) you are not talking about updating a load of app configs on anyones machines. You can make a setting for your own personal use, and other ones for handing out for corp purposes or to friends for advice on fits. Most people won't have more than a handful of API entries, and will be more in the habit of demising leys when leaving a corp than they will have been before. A default view setting which hides demised keys would be ideal, but with the ability to view and reinstate old keys. Originally by: Matalino Originally by: CCP Prism X Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful! Twist some arms if you need to. Having an Advanced Access View is important. Having two layers of granularity allows the top layer to be much simipler than a single layer could be while still retaining a reasonable level of granularity. It doesn't need to be a seperate view: just have the groups as folders than expand to list the API's within them. Since you requested proposals on how to break it down, this is what I suggest for the current API's: Spot On. Matalino, except account/Characters.xml.aspx . A view which showed the group level but allowed outline drill into each API call would be cool, but I am really not sure how much that limits the scalability of the API system itself. if you are using in64s, that might limit you to 64 pages of API call and I for one want to see a much better Tower API expansion, detailing fits and module status, perhaps including ammunition. The templates idea is a really good one, and it would allow corps to take a position on whether or not they are bothered about alt characters on the same account. The argument of separate accounts for the purpose of spying is a strong one against availability of account information from the API, and nobody will ask you for screenshots of all of your accounts on Eve, so the best compromise here is to keep the account's information available, but make it optional and in it's own group.That way, if a corp wants to see it but the pilot (player) doesn't, then presumably the corp won't recruit the player. Account information would obviously not be available on a Character-only key, and would need to be account-bound.
Miss Misses	Posted - 2011.05.27 09:30:00 - [122] please dont do this its working fine as it is no reason to bork it up
Shin Chogan Gallente	Posted - 2011.08.20 11:25:00 - [123] +1 for being able to have a no limit lifespan on a key pair +1 for being able to tell if one or more of the characters on an account is not included in the info - Being able to see the character names and corporations of all the characters on an account can be a valuable tool for spy detection.
Claire Voyant	Posted - 2011.09.01 17:09:00 - [124] I can't find this anywhere, but I assume the security level on the legacy keys are: 0 = limited 1 = full Is this correct?


Pages: 1 2 3 4 5 :: [one 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.