EVE Information Portal

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.

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

You like posting don't you?

I can tell.

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.

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:



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, someone didn't think this through all the way.

I don't /want/ people to cache the data. As I've seen too many caching proxies screw stuff up.

And I'd prefer not to send credentials, even read only ones, clear text.

This might just be a pipe dream but is there any chance of adding access to War Reports to the API? or be able to compile them for viewing via 3rd party apps?

Well I'm really pleased for you that you've had the luxury of writing your own high quality object orientated code, have been able to keep it completely up to date and now only need to change 3 lines of code.

For the rest of us, stuck with maintaining ****** legacy code written by inbred morons (who think an object is something they hit with a hammer) and who have been quietly working away for the last 6 months aware that this issue was coming....

Well WE WOULD APPRECIATE SOME MORE F*CKING NOTICE THAN 2 WEEKS.

We would also like CCP to fix the MASSIVE functionality hole that allows a user to change their CAK after they registered it with our web sites, thereby completely gimping a host of security precautions. (and yes, it was bug reported and commented on extensively with a few weeks of the "new" API Key system being released)

https://forums.eveonline.com/default.aspx?g=posts&t=17150&p=2

Just a sidenote. I know that consistency is not really CCP's cup of tea, but you should use the ISO8601 timezone format, like the website does on most place. It'd make it a lot more consistence, and readable. these randomly ordered formats are a pain, that's why we've got a wordwide standard for it.

This is the problem (not the altering of code).

Explaining to people that they've just entered a key but it's detected that it needs more just to maintain the same level of service they are used to with Legacy keys.

And you have to check the validity of the key on every use because the user might have gone back to the Eve website and changed the privileges for the key.