EVE Technology Lab

Uhhh, you spent time building something, without taking a look at what CCP were going to do? CREST has been out for a fair time now. ESI was announced 2 months ago.

And it's CCP's fault?

The "mostly code illiterate" folks (me) who do "stuff"(also me) with the current XML api got a big kick in the junk with ESI.

CSM is useless position in CCP. CCP doesn't listen it at all. ;) CSM is some kind of "throughts collector". When he\she collects thoughts he announce them to CCP. And that's all.

I aggree with you man. As I said earlier they doing api such way that only developer (in rl) can handle their API (FOR FREE, you cannot ask real money for it!). And in the end - their api will die. It's dieing now...


We need ready api with full manual or just close all uncomplete branches - what for are they? They confuse anyone who tries to create something... They only shows that ccp pay someone money to create new some api and then fire it.

I see it in this way.
Was a person group that creates XML API (hello old school! you are great). Then came new group that creates CREST... But wait! Lest create SSO! Another group of devs came? LOL And now new (afaik) came to develop that ESI....

So CCP spent their money ... For what!? LOL

Your problem that you hiring wrong guys, and I think not for "free"...

PS: When you work developer a lot, you know how it goes in another companies.

PS2: CSM is a regular person, don't rely on him\her, he cannot affect at all, he\she can only suggest. And mostly CCP refuse suggestion. I talked to CSM guys a lot, it's only fiction that you can change something, it's same like you post your thought on this forum.

Hate to tell you this, but your suppositions on _why_ the new APIs happens is wrong. Which is fairly obvious to anyone who interacts with the wider Eve third party community. Where the developers involved are actually pretty responsive.

Will there be a full manual for the API? I seriously doubt it. There's documentation now, with ESI. That's a bonus from the way they're doing it. Swagger pretty much means that there is some documentation.

The XML api has _severe_ limitations, mostly stemming from how it interacts with Eve. (It talks directly to the database. Which doesn't contain full state)

Crest was primarily created for the Dust integration, allowing for some limited interaction with game state.

CREST has some other limits, and wasn't suitable for the mobile app, which is the main driver for ESI. There are devs who have some and gone in that time, but that's just people moving from companies. It happens. Not people being fired.


As for why some things are taking longer to port than you might expect: Eve's complicated. And this is trying to graft functionality which was never designed into it. Assumptions which made perfect sense when they were made, no longer do, and cause problems. One of the big problems is sessions. Eve was designed for a single session per user. The API (other than XML, but that can't actually do anything which would need one) would need a second. Which breaks things. so fun for everyone involved

Thanks steve but this is what im talking about, you showed me a crest example, not a esi example, then referenced the esi latest again which is useless as it doesn't show me how to actually use it with php from my local testing environment.

Example: how do i, from scratch, simply get the wallet of my own character.

for example, i have this so far, and that's it, where the hell do i start lol. I know its a lot to ask but so frustrating without a clear example for less experienced devs. I can work laravel pretty well but cant figure out this sso crap to save my life

"$authorization = "Authorization: Bearer how the hell do i get this, from where, what process";
$ch = curl_init("https://esi.tech.ccp.is/latest/characters/{character_id}/wallets//?datasource=tranquility");
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
$authorization,
));
// curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// curl_setopt($ch, CURLOPT_POSTFIELDS,$authorization);
// curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
// curl_setopt($ch, CURLOPT_POST,false);
$result = curl_exec($ch);
//dd($result);
curl_close($ch);
return $result;"




hopefully someone will whip up a CLEAR laravel package :)

I meant a package for only esi for laravel. A man can dream right?

Id take a one page script showing me how to pull the data i asked for above (wallet) , i can get the rest from there. IM looking through the link steve posted i think i see it in his examples but i have to try to make it work

If its a simple as they claim it should be dead simple to show me a one page php example that can grab the wallet right?

I'm using phealng right now and i have that all figured but how long is crest going to be around? i heard 16months, true?

Laravel isn't a framework I've used. And I'm not planning on learning it

However, you get the authorization header in exactly the same way as you do with CREST. You just request ESI scopes, rather than CREST ones. Nothing has changed, with regards to the SSO.



Some links which _may_ be useful:
http://stackoverflow.com/questions/29441954/laravel-oauth2-client-authorizing-and-redirecting-with-guzzle


(Things can be a touch confusing, because there are packages to make laravel a oauth server, as well as a client. You just need it to be a client)



Short explanation of OAUTH 2:

The user clicks on login. This is normally a link directly to the login server, in this case, at CCP. This link contains your client ID, where to send the user back to (CCP have set this so it _must_ match what you set in the developers site), the list of scopes that you want (space seperated), and a state id. (The state isn't needed. but is handy if you want to make sure a session exists. Or want to store where to send the user back to, or something along those lines)

Once the user has authenticated, and approved scopes, they're sent back to your site, using the url which you passed (for CCP's, this must be what's in their database) along with a token.

The site must then take that token, and send it to CCP along with their clientid and secret ( base 64 encoded).

CCP then send (as a response to the site. This happens entirely server side, between the 2 servers) an access token, and a refresh token. (if no scopes were requested, it's just the access token) There's also a character owner hash (this is non standard) which lets you know if a character is moved between accounts. If it changes for a character, it's changed account.

You now have your access token, and your refresh token.



You can see the communication between the sites on https://github.com/fuzzysteve/fleetTracker/blob/master/auth.php

This is the same regardless of if you want to use CREST or ESI.


In my example, the login is handled by a redirect, rather than a direct link. This is just so I can set up a few session variables first. https://github.com/fuzzysteve/fleetTracker/blob/master/login.php


The access token is only valid for 20 minutes. Once that expires, the token is useless.

If you have a refresh token, you can use this to get a new access token at will. That's what the refresh_token() function does in the following file.

https://github.com/fuzzysteve/fleetTracker/blob/master/auth_functions.php#L9

Okay. But where it's written mate? Only by this post I learn that api-url is relative. And what about others? They should search this post to understand that? That's I'm talking about! "API described somewhere in a forum... Search and you will find... Maybe..." - is a bad manual. =\

Thanks Steve, appreciate all the help. I'll see what i can come up with :)