| Author |
Thread Statistics | Show CCP posts - 53 post(s) |
Kaladr
Eventually Consistent
41
   |
Posted - 2014.11.22 05:31:53 -
[1] - Quote
Since EVE-Central will be supporting reading from this endpoint, we'll need access to the test setup :)
EVE-Central.com Market Order Feed
5aff81b988b54f81940dad11e98bf784
Is the authentication flow / specifics documented anywhere?
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
41
|
Posted - 2014.11.24 07:22:49 -
[2] - Quote
Kali Izia wrote:Kaladr wrote:Is the authentication flow / specifics documented anywhere? Initially you follow the same flow as the normal SSO auth with these differences: 1. On your call to /oauth/authorize, set your scope to "publicData" 2. On your call to /oauth/token, you now get a refresh_token in the response 3. On future calls to /oauth/token, you can use the refresh token by changing the grant_type to "refresh_token", and send the token in a "refresh_token" variable rather than a "code" So instead of this: POST https://sisilogin.testeveonline.com/oauth/token
grant_type=authorization_code&code=xxx You do this: POST https://sisilogin.testeveonline.com/oauth/token
grant_type=refresh_token&refresh_token=yyy 4. When accessing the CREST resource, just include your "Authorization: Bearer $access_token" header
The good news is, minus the scope (which isn't on my app yet) the handshake is conforming to OAuth2 so I didn't have to futz with it too much.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
41
|
Posted - 2014.11.24 18:59:45 -
[3] - Quote
CCP FoxFour wrote:Kaladr wrote:Since EVE-Central will be supporting reading from this endpoint, we'll need access to the test setup :)
EVE-Central.com Market Order Feed
5aff81b988b54f81940dad11e98bf784
Is the authentication flow / specifics documented anywhere? I couldn't find this on Sisi. Please create it on developers.testeveonline.com
Derp.
EVE-CENTRAL.COM MARKET FEED (SISI)
2dd9a45abbe94c7482ef1a4421d2c2ca
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
41
|
Posted - 2014.11.28 04:16:40 -
[4] - Quote
I've started a library and scanner for navigating the CREST APIs. There are a bunch of missing features (walking pages, pooled parallel fetching, types beyond Region), but it's capable of acquiring and caching tokens and has a few nice wrappers.
APIs will change to clean them up as the right abstraction is found.
https://github.com/theatrus/crestmarket
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
41
|
Posted - 2014.11.28 08:54:26 -
[5] - Quote
CCP FoxFour wrote:
Your application is going to break on Monday when the route for types changes from /inventory/types/ to just /types/ (don't get me started on why I have to revert that change). I highly recommend NOT hard cording URI's. We do, and will continue, to change routes. Follow links.
Already fixed :-)
Quote:
Also, if I am not mistaken, it appears you are always sending the same accept header "application/vnd.ccp.eve.MarketTypeCollection-v1+json" which for anything other than the market type collection will result in just the newest version.
I was going to bring up this as a question - how are the variants of the API versioned based on the Accept header?
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
42
|
Posted - 2014.11.28 18:51:26 -
[6] - Quote
CCP FoxFour wrote:
Not sure I understand the question. How do we handle it on our end or how do you handle it?
More specifically, what are/are there accept headers to use for stable result versioning for the other resources yet (I.e. Regions, inventory types)?
If you're returning them in a header already I probably missed it.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
42
|
Posted - 2014.11.28 22:33:36 -
[7] - Quote
Perfect!
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
42
|
Posted - 2014.11.30 00:22:06 -
[8] - Quote
Along with the third option is an embedded web view with the in-application URL handler to pick up the redirect.
(Disclaimer: this is significantly less secure for the user since your application would have login credentials effectively typed into it. It is common practice on mobile applications however)
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
43
|
Posted - 2014.11.30 02:08:59 -
[9] - Quote
Nuke Cherenkov wrote:Kaladr wrote:Along with the above two there is the third option of an embedded web view with the in-application URL handler to pick up the redirect.
(Disclaimer: this is significantly less secure for the user since your application would have login credentials effectively typed into it. It is common practice on mobile applications however) To keep the learning curve reasonable (not done any significant web dev), I'm focused more on a single user app (= probably me and some close friends) so this sounds like the best approach. I'm trying to write the Python in a modular enough fashion that it would be useful in a web based app at which point I will follow Steve's advice. This also seems to be helpful to understand the process: https://dev.twitter.com/web/sign-in/implementing ? Thanks to you both!
The process is similar, except that Twitter uses OAuth1, whereas CREST is OAuth2. The concepts of redirecting are similar, just the token steps are different (i.e., OAuth requires signing the requests, whereas OAuth2 simply assumes transport security is perfect and forwards your "secret").
Google uses OAuth2 for its services, and this guide may be more relevant:
https://developers.google.com/api-client-library/python/guide/aaa_oauth
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.11.30 05:11:54 -
[10] - Quote
Steve Ronuken wrote:One option which remains open for people is:
Have a client which sends you to a particular website (forming a session with it)
Have that website redirect people to the auth.
Have the site do all the talking with CCP's server, to get the access token (retaining the refresh token)
Send the access token back to the client.
That way, the client doesn't every see the refresh token, or the other detailed needed to create one. It can just ask the website for a new access token.
The client is also capable of doing authentication by (different) usernames and password, for an added level of security, just storing the refresh tokens against those.
That does make the third party site a juicy source of stored tokens (with various levels of vulnerability depending on the token scope). As flawed as Oauth2 is its better for keeping credentials secret.
I'm fully intending on keeping the EVE-Central market APIs running as long as there are users. CREST will of course be more powerful as it can do so much more depending on future scopes, but for simple R/O access it will likely be simpler for most users.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.11.30 08:40:41 -
[11] - Quote
Pete Butcher wrote:Small question - is it normal that I have to click 'Authorize' every time my app calls /oauth/authorize? It would be really nice if the server remembered which apps were already authorized and just returned the token after login (with 'remember me' functionality in mind).
Thats what the refresh token is for. You should be able to refresh to receive a new bearer token without user workflow.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.11.30 08:44:05 -
[12] - Quote
I've updated crestmarket with a very cheesy proxy mode, letting you get data without going through any OAuth steps for internal applications. Its cheesy (remaps URLs with a global regexp, etc), but may be helpful to some! Do not run this on an exposed interface / the internet / etc 
Details are here: https://github.com/theatrus/crestmarket
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.12.02 06:55:53 -
[13] - Quote
Two quick questions:
Any followup for the availability of the volume entered for an order being exposed?
Any ETA on the /universe/locations/ endpoints be available? Also, the href on an order is currently also not available.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.12.08 16:06:44 -
[14] - Quote
Looking forward to it =ƒÄë
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
44
|
Posted - 2014.12.09 20:57:00 -
[15] - Quote
Thankfully expired after 5 minutes :-)
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
Kaladr
Eventually Consistent
45
|
Posted - 2014.12.20 02:51:05 -
[16] - Quote
I got an out of band reply that it will re-appear in the next 1-2 releases.
Creator of EVE-Central.com, the longest running EVE Market Aggregator
|
| |
|