Pages: 1 2 [3] 4 5 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 8 post(s) |
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 |
|
|
|
|
|
Pages: 1 2 [3] 4 5 :: one page |
First page | Previous page | Next page | Last page |