Pages: [1] 2 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 6 post(s) |
|

CCP Gargant
C C P C C P Alliance
18

|
Posted - 2012.09.19 14:39:00 -
[1] - Quote
CCP Illurkall has a new dev blog available for your viewing pleasure which details the changes coming to the API system this fall. Illurkall is the overseer of the API for the foreseeable future and will make sure it is up to snuff.
You can read all about it here
We would be delighted to receive your (constructive) feedback in this thread. CCP Gargant | Community Representitive |
|

ChromeStriker
The Riot Formation Executive Outcomes
232
|
Posted - 2012.09.19 14:43:00 -
[2] - Quote
First - Nulla Curas |

Peter Powers
Terrorists of Dimensions Free 2 Play
89
|
Posted - 2012.09.19 14:45:00 -
[3] - Quote
CCP Gargant wrote:CCP Illurkall has a new dev blog available for your viewing pleasure which details the changes coming to the API system this fall. Illurkall is the overseer of the API for the foreseeable future and will make sure it is up to snuff. You can read all about it hereWe would be delighted to receive your (constructive) feedback in this thread. can CCP Illurkall please post in this thread so we can LIKE his post? 3rdPartyEve.net - your catalogue for 3rd party applications |

Ferria
Among the Shadows Silent Infinity
7
|
Posted - 2012.09.19 14:49:00 -
[4] - Quote
any news on Crest? |
|

CCP Atlas
C C P C C P Alliance
191

|
Posted - 2012.09.19 14:59:00 -
[5] - Quote
Ferria wrote:any news on Crest?
Here's a recent update from CCP Seagull |
|
|

Chribba
Otherworld Enterprises Otherworld Empire
4863
|
Posted - 2012.09.19 14:59:00 -
[6] - Quote
Sweepin' in with DUST!
|
|

Captain Thunk
Sniggerdly Pandemic Legion
124
|
Posted - 2012.09.19 15:01:00 -
[7] - Quote
CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it. |

iskflakes
Magnets Inc.
64
|
Posted - 2012.09.19 15:06:00 -
[8] - Quote
Captain Thunk wrote:CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it.
Doesn't seem like a big problem to me -- just make 4 CAKs. How often do you have 3 different corporation directors on a single account anyway?
I am pleased to see this dev blog change. There is no reason to support legacy systems forever and plenty of time has passed now. Also, as member of the HTTPS fanclub it's great to see you requiring it going forward.
If any API developers read this, could we maybe get a relaxation of the cache time on the assets API? For my particular application I would like to request asset data more frequently than once every 6 (?) hours. The long cache time is probably the single biggest source of complaints amongst my users. Track your wealth with EVE Stats: https://ohheck.co.uk/EVEStats/home.php |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
189
|
Posted - 2012.09.19 15:09:00 -
[9] - Quote
Captain Thunk wrote:CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it. read: "Even though months and months have passed I have been too lazy to update our software; now that the plug is getting pulled I am shitting myself continuously at the prospect of having to rewrite all my code in the span of 2 weeks" |

Tork Norand
Mechanical Eagles Inc. The Ancients.
114
|
Posted - 2012.09.19 15:12:00 -
[10] - Quote
What? No pretty pictures or graphs?
Not even one showing something like....how many new keys were generated from the time they were offered? 
--Tork. CEO and Herder of Cats. |
|

Captain Thunk
Sniggerdly Pandemic Legion
124
|
Posted - 2012.09.19 15:15:00 -
[11] - Quote
Promiscuous Female wrote:Captain Thunk wrote:CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it. read: "Even though months and months have passed I have been too lazy to update our software; now that the plug is getting pulled I am shi tting myself continuously at the prospect of having to rewrite all my code in the span of 2 weeks"
It takes about 3 lines to make use of new keys. The reason I haven't done so is because, guess what, like I said in my first post - CAKs are not as good as a full legacy key.
|

iskflakes
Magnets Inc.
64
|
Posted - 2012.09.19 15:16:00 -
[12] - Quote
Tork Norand wrote:What? No pretty pictures or graphs? Not even one showing something like....how many new keys were generated from the time they were offered? 
I created a key a moment ago and it gave me the ID: 1327730. The lowest ID I've seen personally is ~5000, and I have observed that creating keys in quick succession gives them consecutive key IDs. So, it's pretty easy to estimate the number of keys ever created at about 1.3 million. Not bad! Track your wealth with EVE Stats: https://ohheck.co.uk/EVEStats/home.php |
|

CCP illurkall
C C P C C P Alliance
2

|
Posted - 2012.09.19 15:20:00 -
[13] - Quote
Hey
I'll try to make my next DevBlog look a little bit more happy with pictures and all. The reason for doing this is mainly an effort to keep the legacy to a minimum and making it easy for us to move forward. Because if we can move forward more freely that just means more stuff for you guys in the end. |
|

Tanaka Aiko
ICE is Coming to EVE Goonswarm Federation
113
|
Posted - 2012.09.19 15:27:00 -
[14] - Quote
I clicked on devblog link hoping for CREST news, left disappointed. |

Akrasjel Lanate
Naquatech Conglomerate
769
|
Posted - 2012.09.19 15:56:00 -
[15] - Quote
Cool |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
191
|
Posted - 2012.09.19 16:25:00 -
[16] - Quote
Captain Thunk wrote:Promiscuous Female wrote:Captain Thunk wrote:CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it. read: "Even though months and months have passed I have been too lazy to update our software; now that the plug is getting pulled I am shi tting myself continuously at the prospect of having to rewrite all my code in the span of 2 weeks" It takes about 3 lines to make use of new keys. The reason I haven't done so is because, guess what, like I said in my first post - CAKs are not as good as a full legacy key. your fault for writing code that relies on a goofy edge case instead of developing a proper application
fortunately for you they aren't actually shutting down old keys, just making it impossible to generate additional legacy keys, so you probably got another couple of months before you have to get off your ass and change "3 lines" of code |

Captain Thunk
Sniggerdly Pandemic Legion
126
|
Posted - 2012.09.19 16:33:00 -
[17] - Quote
Promiscuous Female wrote:Captain Thunk wrote:Promiscuous Female wrote:Captain Thunk wrote:CAKs fail to encompass the abilities of its predecessor the legacy API key.
A full legacy key allows access to everything available with the account, with a CAK you are limited to 1 char, All chars or 1 Corp.
This means to equal 1 full legacy key you will need upto 4 CAKs per account. 1 CAK for all the chars and if there are 3 chars, each a director or CEO of a different corp then 1 CAK for each of them.
There is no reason for this backwards step, you can maintain the ~security~ CAKs are meant to achieve and still have an option to access ALL data for those that want it. read: "Even though months and months have passed I have been too lazy to update our software; now that the plug is getting pulled I am shi tting myself continuously at the prospect of having to rewrite all my code in the span of 2 weeks" It takes about 3 lines to make use of new keys. The reason I haven't done so is because, guess what, like I said in my first post - CAKs are not as good as a full legacy key. your fault for writing code that relies on a goofy edge case instead of developing a proper application fortunately for you they aren't actually shutting down old keys, just making it impossible to generate additional legacy keys, so you probably got another couple of months before you have to get off your ass and change "3 lines" of code
I did the changes 12 months ago, I simply disabled it because instead of asking for multiple keys and doing the necessary checking to make sure all have been entered I could just stick to 1 legacy key as it's just much better.
It was originally written when CAK didn't exist, so your spouting about "developing a proper application" is just stupid nonsense being spewed by a kid who just collected his Basic Computing certificate last week. Shutting down legacy API at this juncture serves no purpose other than to supply reason for a devblog. It's a system that happily runs itself and no-one is planning on adding anything to the API or working on it in any manner as all efforts are concentrated on CREST.
My only crime is that I am one of the few people who actually use all of the available API which is why hoopleheads such as yourself keep spouting rubbish about "should have updated" oblivious to the limitations that CAK pose compared to their predecessor. |

Sentient Blade
Walk It Off LEGIO ASTARTES ARCANUM
482
|
Posted - 2012.09.19 16:51:00 -
[18] - Quote
Now if only there was JSON... |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
191
|
Posted - 2012.09.19 16:59:00 -
[19] - Quote
Captain Thunk wrote: I did the changes 12 months ago, I simply disabled it because instead of asking for multiple keys and doing the necessary checking to make sure all have been entered I could just stick to 1 legacy key as it's just much better.
It was originally written when CAK didn't exist, so your spouting about "developing a proper application" is just stupid nonsense being spewed by a kid who just collected his Basic Computing certificate last week. Shutting down legacy API at this juncture serves no purpose other than to supply reason for a devblog. It's a system that happily runs itself and no-one is planning on adding anything to the API or working on it in any manner as all efforts are concentrated on CREST.
My only crime is that I am one of the few people who actually use all of the available API which is why hoopleheads such as yourself keep spouting rubbish about "should have updated" oblivious to the limitations that CAK pose compared to their predecessor.
that's an awful lot of :words: for "i'm too lazy to update my application"
also i guess you missed the locations, charactername, and contracts api stuff that they added after announcing crest |

Hatsumi Kobayashi
Sniggerdly Pandemic Legion
205
|
Posted - 2012.09.19 17:33:00 -
[20] - Quote
CCP illurkall wrote:Hey I'll try to make my next DevBlog look a little bit more happy with pictures and all.  The reason for doing this is mainly an effort to keep the legacy to a minimum and making it easy for us to move forward. Because if we can move forward more freely that just means more stuff for you guys in the end.
CAKs are a step backward.
CAUTION
SNIGGS |
|

Captain Thunk
Sniggerdly Pandemic Legion
127
|
Posted - 2012.09.19 17:36:00 -
[21] - Quote
Promiscuous Female wrote: that's an awful lot of :words: for "i'm too lazy to update my application"
also i guess you missed the locations, charactername, and contracts api stuff that they added after announcing crest
I remember back when Goons could troll well 
Now it's all generic paint-by-numbers nonsense.
|

Steve Ronuken
Fuzzwork Enterprises
655
|
Posted - 2012.09.19 17:37:00 -
[22] - Quote
Hatsumi Kobayashi wrote:CCP illurkall wrote:Hey I'll try to make my next DevBlog look a little bit more happy with pictures and all.  The reason for doing this is mainly an effort to keep the legacy to a minimum and making it easy for us to move forward. Because if we can move forward more freely that just means more stuff for you guys in the end. CAKs are a step backward.
You mean how they introduced functionality that the legacy keys didn't have? Namely the ability to limit what you're handing someone, so, for example, you don't need to give your killboard a key that has access to anything other than your kill data?
Yes, Captain Thunk is right that it removed one bit of functionality. But it's one that's /easily/ simulated, with 4 keys. What it added was impossible with the legacy system. FuzzWork Enterprises http://www.fuzzwork.co.uk/
Blueprint calculator, invention chance calculator, isk/m3 Ore chart-á and other 'useful' utilities. |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
191
|
Posted - 2012.09.19 17:44:00 -
[23] - Quote
you can hardly call "3 ceo characters on one account" to be typical usage and worth stringing along an old, insecure system whose only other redeeming feature was making it easy to determine whether a person is worth scamming |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
191
|
Posted - 2012.09.19 17:45:00 -
[24] - Quote
and the new system is just as easy because you can just hand them a CreatePredefined link and 90% of people won't bother looking at the checkboxes |

Promiscuous Female
GBS Logistics and Fives Support Goonswarm Federation
191
|
Posted - 2012.09.19 17:45:00 -
[25] - Quote
but seriously you've had how many months? to cut your system over and you're choosing just now to complain |

Captain Thunk
Sniggerdly Pandemic Legion
127
|
Posted - 2012.09.19 17:48:00 -
[26] - Quote
You like posting don't you?
I can tell. |

Andski
GoonWaffe Goonswarm Federation
4764
|
Posted - 2012.09.19 18:00:00 -
[27] - Quote
too bad thunk is actually right since getting corp data requires a corp director key, as opposed to being able to use, say, a junior accountant key to get wallet data through the API, which was possible with the legacy keys please leave |

Kearl
Sniggerdly Pandemic Legion
2
|
Posted - 2012.09.19 18:43:00 -
[28] - Quote
Id say the dev working on this project is a bit better at lurking then actually responding.
+1 for Thunk
This change makes it easier for scammers/crooks and harder for people trying to catch them. |

Liang Nuren
Heretic Army Heretic Nation
2245
|
Posted - 2012.09.19 19:37:00 -
[29] - Quote
CCP illurkall wrote:Hey I'll try to make my next DevBlog look a little bit more happy with pictures and all.  The reason for doing this is mainly an effort to keep the legacy to a minimum and making it easy for us to move forward. Because if we can move forward more freely that just means more stuff for you guys in the end.
Hey, fantastic blog and good changes. Thanks!
-Liang Normally on 5:00 -> 9-10:00 Eve (Aus TZ?) Blog: http://liangnuren.wordpress.com PVP Videos: http://www.youtube.com/user/LiangNuren/videos
Twitter: http://twitter.com/LiangNuren
|

87102-6
Republic Military School Minmatar Republic
0
|
Posted - 2012.09.19 21:43:00 -
[30] - Quote
Oh dear. It appears to me someone (likely multiple people) at CCP haven't thought this all the way through. I see this time and time again in the actual IT industry as a whole, so I'm not too surprised. I'm a UNIX SA / NA by profession (almost 20 years worth) so I hope what I say holds some weight.
Before I get started, I want to make something crystal clear: I'm not here to talk about the API semantics or the actual API protocol. I know nothing of it therefore am staying away from that topic. What I am going to talk about pertains to 1) use of HTTPS, and 2) the redirections proposed circa 2012/10/04.
1. Use of HTTPS (that is HTTP + SSL) has one major drawback which many administrators overlook: things like caching proxies cannot cache the data. Instead, it then becomes the HTTP client's responsibility to handle caching. This means quite simply that every HTTP request has to return data; things like ETag negotiation (used for caching) don't work well with HTTPS. Combine that with the added SSL overhead and you've got something that uses a lot more bandwidth for something that's probably doesn't need SSL.
And don't even get me started on the SSL cert ordeal -- CCP has historically forgotten to renew their certificates many times in the past:
http://community.eveonline.com/ingameboard.asp?a=topic&threadID=791627 http://www.eve-search.com/thread/909495-0/page/1
Basically whenever people start advocating use of SSL without providing full 100% justification up front, I am left with the impression that there is probably no justification for it. Instead it's "security through paranoia".
What exactly gets transmit, API-wise, between client and server that mandates use of SSL? All I'm able to tell from the official API Functions wiki document is that the client's HTTP GET params connsist of a "userID" and "apiKey". So let's say there's a MITM attack going on, or someone capturing plaintext HTTP packets. They can get a user's user ID and API key. And what exactly does that get them? The API Key management page states quite clearly the following:
Quote:Is this safe? Can someone steal my account?
It is safe to provide your API key to applications and web sites as long as you are prepared to allow the application or web site to see your character and corporation information. You can specify which information is accessible for each customizable API key.
Sharing an API key does NOT give people access to your account while sharing your account password would. Therein lies the whole purpose of API keys. An API key only allows the recipient to view your character and corporation data but gives them NO control over it. They are NOT able to log in to the game or post on the forums with the API information. No part of the API key information is in any way generated from your account password - there is no way to calculate your password using this information.
So based on this, it appears to me that about all a person could do is then gain access to the information provided by the API -- none of which involves transactions of money/finances, or ability to change character data, nor does it have anything to do with actual EVE accounts (as in the accounting part).
So again: why SSL? Politely: justify it. Unless you plan on extending the API to allow people to make changes in some way, I just don't see the point.
Now for the 2nd item:
2. Redirections. The dev blog post specifically states, quote:
This is a very, very bad idea from a protocol perspective. You are making a blind assumption that the clients using the HTTP (non-SSL) semantics have support for SSL. That is a very, VERY bad assumption. Let me expand:
If you redirect clients blindly from a plaintext HTTP protocol (on TCP port 80) to an encrypted HTTP protocol (on TCP port 443), and the client does not support SSL, the client submitting the API request will break. Badly. Very, very badly. The same problem applies if the client does not honour HTTP 3xx redirection status codes (for example, libcurl can be adjusted to not follow these, and things like perl's LWP do not necessarily follow redirections blindly.). In either case, the client will throw back a generic protocol error to the user (assuming the client has error checking code in it that's even remotely decent -- others might just downright crash).
Then there's the issue of CommonName support (SSL cert-wise) when doing an HTTP-to-HTTPS redirect. Client which supports SSL visits http://api.eveonline.com/ and gets redirected to https://api.eve-online.com/ (note the hyphen). The client's SSL library may result in a certificate verification failure, since the requesting Host of api.eveonline.com does not match the CommonName of api.eve-online.com. What the client sends and what the server's SSL cert contains CommonName-wise need to match: ALWAYS.
My professional recommendation: don't redirect anything. Just simply shut down the non-SSL services (disable them in your load balancer, etc.) entirely. This will result in a clean failure for clients which need to be upgraded. Don't respond to the TCP SYN that comes in to TCP port 80 (or if you want, return TCP RST / ICMP port unreachable). Let the client handle that situation cleanly, and force the client authors to switch the API URL in their software. It's really the best choice here.
Hope this gives you and your SAs something to think about, because from what I can tell, som... |
|
|
|
|
Pages: [1] 2 3 :: one page |
First page | Previous page | Next page | Last page |