EVE Technology Lab

Hi Devs,

I am wanting to use CREST to get some of the market data that is behind the auth'd part of the API but I am building a 'fat' application rather than a web based one.

All the information I can find on the auth process sees to point to the fact that I have to use a website (for the call back)... Is this the case or can I just ignore that part of the request if I don't want to be called back?


Thanks in advance.

Thanks Steve, really appreciate you taking the time.

So this app is a one off that I will be using my self. It has a number of accounts to access but only me as a user.

I am using VBA (or C# classes I write and put in to access) so if I am reading this right I am screwed right?

-CJ

In Evernus I offer two ways of doing auth - by internal and external browser. The user can choose which method he prefers. Using the internal browser guarantees that everything will work on pretty much every system with any configuration, but it presents a trust issue for the users. Using the external browser moves the trust issue onto it, so the application becomes more trustworthy, but the user experience is worse because of switching between apps and you have no control of the process.
The way to handle external browser sounds easy in theory like Steve said, but it's more problematic in practice. Custom scheme will require you to promote the privileges to register it (and you need to validate it every time), which makes the app useless in most corporate environments, for example, or when current user simply doesn't have admin privileges. Local server has a similar problem - the user needs to have rights to open a port, which again might be not possible due to system security policies or firewall. And if you decide to make a multiplatform app, things get even more complicated.
In the end you have to think what environments you're targeting and choose the best method.

Afraid not as such.

The Auth portion is pretty much vanilla OAUTH2

The endpoints currently available are pretty much just 'GET the endpoint, with an auth header'. Except for the market order ones, where you have to pass in a typeid href as a parameter.

Foxfour is working up some documentation, which will be available in json. https://www.fuzzwork.co.uk/crestDocumentation.php is hooked up to dev version of it.


The key, in general, is not to hard code any url except the base (https://crest-tq.eveonline.com for TQ), and derive /all/ other hrefs from that.

For the basic oauth2 flow, there is a fairly good walkthrough on the dev site.

Subject to some things which are now out of date:

- Tokens are now valid for 20 mins, not 5.
- That guide states that refresh token is always null, it does now return one and this can be used to get a new auth token at any time (no expiry). (no docs on this afaik, it's standard oauth2 stuff though, so google is your friend)
- There is now one scope available to request "publicData" - only used for market orders at this time

There is other info, but it's spread around posts in this forum, often on page 8 of a long thread or similar. Hence the other thread about documentation!

If you have the refresh token, you need to obtain the access token, which is then used to make other requests. Make a request to /oauth/token with grant_type=refresh_token&refresh_token=... as data and Authorization: Basic base64((clientID):(secret)) in the headers. You'll get the access token, which should be appended as Authorization header to other requests, as described on https://developers.eveonline.com/resource/single-sign-on .

So just to compete the loop for other who come searching..

Using the json parser in the post above here, I was able the read the JSON in Dictionaries and move on from there.

Got the Authed Crest working also by using the google plugin mentioned above to setup the first authentication allowing access to a refresh token.

Happy to share the VBA for the Authentication if people want it ping me an eve mail




Thanks for all the support guys, much appreciated!


-CJ