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