EVE Technology Lab

Hi Guys,

It seems odd that the ESI doesn't appear to allow retrieval of character IDs. Do we need to continue using the legacy API to get those before we use the character features in the ESI?

I get...
404 https://esi.tech.ccp.is/latest/characters/?datasource=tranquility
400 (character_ids required) https://esi.tech.ccp.is/latest/characters/names/?datasource=tranquility

Also, I find it odd, in terms of a web API, using a parameter for the database used. Typically parameters in a GET request are meant as optional filters, not mandatory ones. Mandatory stuff usually goes as a path parameter in a hierarchical kind of way. i.e. database would be first, sub-paths next. e.g.
https://esi.tech.ccp.is/latest/tranquility/characters/names/?character_ids=1,2,3

Also, it seems webisms are being avoided in the area of character_ids above as well. Comma separated? That's just weird. It's similar to having a relational database with columns that store delimited text, rather than creating columns for the fields being stored in that delimited text.

It would be more appropriate to be...
https://esi.tech.ccp.is/latest/tranquility/characters/names/?character_id=1&character_id=2&character_id=3

Of course the question remains: why can't we extract a character ID from ESI after succesfully retrieving an access and refresh token from the SSO? Like the OP, I find it odd that I have to go back to an older API to find out who just authorized my application to extract data.

The "GET" request to "https://login.eveonline.com/oauth/verify" does give me back a character ID and name but still I would like an ESI endpoint to get that information from.

You're correct.

Yeah... i'm confused

So you use SSO -> OATH -> ESI ? and was the answer "yes, you need to get Char Id from previous apis"

Plus making folks use a "Web" interface for authentication is limiting client-side development.

Ok so its still the as per usual way of scope + token matching



Not really, if you factor in solutions like Mono (x-pat) you're not exactly going to embed a browser or port into the device to act as a catchment for response(s) back. If you also were to make the UI with Unity3D you'd have zero chance of success either given it uses a mono subset. The point is there are a plethora of pathways to take for security this is just lazy architecture.



There in lies my previous point. There's no affordance or deterrent really other than social justice to deter bad behaviour. In WinForms/WPF, for example, you could easily just abstract the whole SSO from the user by providing UI controls for username/password and then just invoke the form post on once the page has loaded via DOM injection.

Now I'm sure buried in the TOS / EULA there's a clause saying don't do that, but that's not enough for "security". Keeping in mind that if you made an app that exploits Eve or its Market/Trade system users would give over their PayPal accounts almost in a way to get access to it. Never underestimate the power of desperation of a user as its more about solicitation then tech style Yelp! reviews.

I'm a former Product manager for. NET, rest assure I'm up to speed on the possibilities here, suffice to say we did a survey on virus infection for Windows once, we found that IT professionals would knowingly install a virus *if* the content was worth the risk...

SO my point really here is that one could potentially wrap this up into a better approach than just "abort client tech revert back to browsers then back to client tech".

It simply a technical population control mechanism and IMHO will continue to starve smarter client-apps innovation.

The plumbing as I see it's in place already. The negotiation between Client <-> Server for accessing trust around data should *never* bring the core master Eve game accounts into the same pipeline. Your actual "Eve" login should be kept separate from this process altogether to disable any hint of misuse as there isn't any actual value in authenticating as a user outside CCP's needs (change password, billing updates etc etc).

• CCP only need to verify an "app" is unique via the normal embedded ClientID/SecretCode Kev/Value pair.
• User only needs to agree to trust said unique app via again Key/VerificationCode Kev/Value pair.

Having Scope attaches should be defined as-is via the Support Key system to date (nothing wrong with this model given you have also access masks to match)

When a User agrees to attach itself to the App(s) they, in turn, can still control what is seen and can retain a sense of permission portability. The Apps themselves don't' care "how" you get the Kev/Value combination they just expect you to have it. In the event they do care, then we're back to this hybrid "CCP owns the login form" problem again. Which isn't required as the only realistic adjustment here is to retain a sense of User Experience which goes out the window anyway, as you're back to shifting the UX debt to a different ledger.

The cognitive load imposed on the current SSO Form with its scopes is essentially "Agree or Disagree" affordance. The user really isn't in control should they disagree and moreover, the information being pushed back to them is obscure and holds no solicitation value outside of "You just need to really trust me" (extraneous cognitive load vs intrinsic cognitive load).

From a developer perspective you just need to encode 2x Base64 encoded strings (even salted if you really want) into the HttpRequest headers. Then move on with your focus on getting into the API's.

The issue to date is the barrier to entry into this mess is simply a tedious hyper string sensitive displacement.

Using this approach going forward CCP can blast the users with explicit messaging like "Our website is the only one who will ever ask you for credentials" and push the messaging even harder to separate that pairing with any 3rd party application will never ask you to login, but will ask for a key/authcode pair... You can get this via your customer portal *only*.

Right now, it's completely wide open to as you mentioned form sniffing via Social hack(s). Now given the demographic of Eve and constant noticeable "scamming" that takes place (plus the $0-$28,000 USD per pilot valuation), I'm just not entirely convinced the honourable of all pilots are pure ;) .... too many war stories counter that point hehe.

OAuth2 isn't meant for this kind of thing unless there's a direct relationship back to the core account. If all you're doing is wanting to build a pairing between a client and a public api, keeping the two seperate is really ideal as the whole point of the public API for the game is to assume 100% of the time the client is always dishonest (for safety reasons).

Case and point:
https://github.com/Frosty-nee/rlel

So to me, the question still retains importance "what are you securing again and why?"