These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

EVE SSO/OAuth possible non-interactive in a cron script?
Author
Previous Topic Next Topic
Ethan02
Succurit Research and Development
#1 - 2016-11-17 12:31:38 UTC
Hello knowledgable people,

I'm completely blank on the topic of SSO/OAuth, but now with some interesting endpoints on ESI that require auth, I need to get my head around it, if I can pull that data into my local database for further mangling.

While reading and searching I haven't been able to clearly answer the main question relevant to me:

Is it possible to query a ESI endpoint like "/universe/structures/{structure_id}/" that requires auth in a cron script?
Meaning non-interactively, by supplying the needed authentication data as parameters. Yes or no?

If yes, if you know any documentation or implementations of this, they would be highly appreciated aswell.

Thank you,
Ethan02
Muscaat
EVE Markets
#2 - 2016-11-17 12:40:14 UTC
It's possible if you do a little work beforehand. If you step through the auth process manually to the point where you have a client ID, secret and the refresh key from an authenticated character, those are the three components you need to be able to obtain a fresh access token each time and use it in your requests.

So something like


  1. Set up a new account at http://developers.eveonline.com and note its client ID and secret. Use a URL like http://localhost/callback as the callback URL.
  2. Construct yourself the auth URL, and go to it in a browser. You'll end up redirected to http://localhost/callback (which won't exist and will give you an error) but in the URL will be the authorization code you need for the next step.
  3. Verify the authorization code. Make a note of the refresh token.


Then in your cron script you'll want to

  1. Use the client ID, secret and refresh token from earlier to get a fresh access token
  2. Use the access token in your ESI request.


https://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/index.html is useful for reference!

(This all assumes you just want some access using your own EVE account, and you're not trying to create something for public use.)
Ethan02
Succurit Research and Development
#3 - 2016-11-17 12:45:44 UTC
Excellent answer, thanks. Will fiddle with that.
March rabbit
Aliastra
Gallente Federation
#4 - 2016-11-18 13:06:19 UTC
Hi! After trying for few days i'm stuck on step 3 (verifying auth code).

Response to my POST:
Quote:
{"error":"invalid_client","error_description":"Unknown client"}


instruction gives pretty straightforward procedure.

I've constructed HTTP address and used it in browser. Got authorization window and stuff (it means i got clientID correctly doesn't it?), error while redirecting and needed address in address bar.

Grabbing authorization code from it and posting with 
curl -v -X POST --header "Authorization: Basic NzY1N...gxbwo=" --header "Host: login.eveonline.com" --header "Content-Type: application/x-www-form-urlencoded" --data "authorization_code&code=vDrg...jn7ta0" https://login.eveonline.com/oauth/token


... And then: quoted early response.

I've rechecked client ID (this is alpha-numerical code and not name of application?), secret ID, base64 encoding/decoding.
Anything seems ok but.... Sad

Any ideas what's going wrong here?

Thanks beforehand

The Mittani: "the inappropriate drunked joke"
David Davaham
Deep Blue Logistics
#5 - 2016-11-19 04:01:40 UTC
March rabbit wrote:


Grabbing authorization code from it and posting with 
curl -v -X POST --header "Authorization: Basic NzY1N...gxbwo=" --header "Host: login.eveonline.com" --header "Content-Type: application/x-www-form-urlencoded" --data "authorization_code&code=vDrg...jn7ta0" https://login.eveonline.com/oauth/token




This part right here


--data "authorization_code&code=vDrg...jn7ta0"



It is suppose to be



--data "grant_type=authorization_code&code=vDrg...jn7ta0"

Developer of EVEmail
March rabbit
Aliastra
Gallente Federation
#6 - 2016-11-19 09:39:00 UTC  |  Edited by: March rabbit
Thanks. But the problem persists.

I believe it is something with Basic Authorization. Maybe it needs to be done another way?

I've made a string client ID:secret key and piped it to Linux utility base64.
Feeding result to 'base64 -d' i get original string so it is not encoding itself. But maybe i messed something with data?
It would be great to see the whole request which is generated and Sent by sURL

EDIT:
I found a problem: it appears that i've got EndOfLine encoded with my text. Using online tool for encoding/decoding i've got different result and using it i was able to get token \o/

The Mittani: "the inappropriate drunked joke"
YeuxVerts Belle
Royal Amarr Institute
Amarr Empire
#7 - 2016-11-23 06:17:04 UTC
Bumping the thread, as my question seems relevant.

I'm still used to the XML API keys. With CREST and ESI, is this SSO protocol the only way to get access to authenticated endpoints ? It seems overly complicated for what i have in mind, which is fairly close to the original poster's wish.

The above message presents my opinions on the topic at hand. If there is a conflict between my views and reality, consider reality to be correct until proven otherwise.
March rabbit
Aliastra
Gallente Federation
#8 - 2016-11-23 06:25:04 UTC
YeuxVerts Belle wrote:
Bumping the thread, as my question seems relevant.

I'm still used to the XML API keys. With CREST and ESI, is this SSO protocol the only way to get access to authenticated endpoints ?

It looks like it is.

YeuxVerts Belle wrote:
It seems overly complicated for what i have in mind, which is fairly close to the original poster's wish.

You can get around SSO 'all the time' by doing some steps only once for your project (logging -> getting auth code -> getting refresh token).

The Mittani: "the inappropriate drunked joke"
YeuxVerts Belle
Royal Amarr Institute
Amarr Empire
#9 - 2016-11-23 06:36:17 UTC
Alright, thanks.

The above message presents my opinions on the topic at hand. If there is a conflict between my views and reality, consider reality to be correct until proven otherwise.