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.
 

Dev Blog: Welcome to developers.testeveonline.com

First post First post
Author
Chingy Chonga
POS Party
Ember Sands
#61 - 2014-10-20 03:11:47 UTC
I'm probably a little late to the game, but I just threw together an example of SSO being used in an android app:
https://github.com/w9jds/EveSSO-Android-Example
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#62 - 2014-10-20 05:37:31 UTC
Chingy Chonga wrote:
I'm probably a little late to the game, but I just threw together an example of SSO being used in an android app:
https://github.com/w9jds/EveSSO-Android-Example



Just checking (as I'm not that familiar with android development, to be able to follow the process). Are you throwing the user out to their browser of choice, then having them come back via a custom protocol, or are you handling it within the application?

(Because if it's the latter, you're doing it wrong. Eve credentials should not be given to an application. Because it requires a far higher degree of trust of the developer not to be doing something nefarious behind the scenes.)

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Sephira Galamore
Inner Beard Society
#63 - 2014-10-20 07:23:28 UTC
Steve Ronuken wrote:
Chingy Chonga wrote:
I'm probably a little late to the game, but I just threw together an example of SSO being used in an android app:
https://github.com/w9jds/EveSSO-Android-Example

Just checking (as I'm not that familiar with android development, to be able to follow the process). Are you throwing the user out to their browser of choice, then having them come back via a custom protocol, or are you handling it within the application

I had a quick look.

What his app does, from what I can tell:
1. Show a WebView in the Login-Dialog that initially loads the SSO URL: [...]/oauth/authorize?response_type=code[...]
2. Upon page load recognize if it's a redirect after successful sign-on
2a. After a successfull login, read the "code" query parameter from the redirect url and request a token via a /oauth/token for this code
Chingy Chonga
POS Party
Ember Sands
#64 - 2014-10-20 17:23:15 UTC  |  Edited by: Chingy Chonga
Sephira Galamore wrote:
Steve Ronuken wrote:
Chingy Chonga wrote:
I'm probably a little late to the game, but I just threw together an example of SSO being used in an android app:
https://github.com/w9jds/EveSSO-Android-Example

Just checking (as I'm not that familiar with android development, to be able to follow the process). Are you throwing the user out to their browser of choice, then having them come back via a custom protocol, or are you handling it within the application

I had a quick look.

What his app does, from what I can tell:
1. Show a WebView in the Login-Dialog that initially loads the SSO URL: [...]/oauth/authorize?response_type=code[...]
2. Upon page load recognize if it's a redirect after successful sign-on
2a. After a successfull login, read the "code" query parameter from the redirect url and request a token via a /oauth/token for this code



That is correct. I use a webview (which is basically a browser in the app) to display the url for authorization. I then listen for when it goes to redirect you to your specified redirect url. I then handle the next two calls (token, and verify) by doing a post and get and then just return to the screen with the login button. Nothing nefarious I promise :)
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#65 - 2014-10-20 17:30:01 UTC  |  Edited by: Steve Ronuken
So the auth step is handled within the application, rather than forcing you out to your regular browser, then back in?

It's a bad practice, and not recommended for oauth. Users should be trained to always go and check the URL, and if that's not available, they should say 'lol, no' to using the app. Anything else is just asking for trouble.


The rest of it is fine though Smile The only real difference is handing it off, then using a custom protocol to bring it back in.

While it's not used in many place, the old XML api can do it (if you pass an install parameter, iirc). It then creates an eve:// protocol link, which applications can register with. I'm pretty certain Aura, for example, can do it.

(If I'm misunderstanding, I apologize. I've had a bunch of arguments with people about this already)

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Chingy Chonga
POS Party
Ember Sands
#66 - 2014-10-20 17:43:53 UTC  |  Edited by: Chingy Chonga
Steve Ronuken wrote:
So the auth step is handled within the application, rather than forcing you out to your regular browser, then back in?

It's a bad practice, and not recommended for oauth. Users should be trained to always go and check the URL, and if that's not available, they should say 'lol, no' to using the app. Anything else is just asking for trouble.


The rest of it is fine though Smile The only real difference is handing it off, then using a custom protocol to bring it back in.

While it's not used in many place, the old XML api can do it (if you pass an install parameter, iirc). It then creates an eve:// protocol link, which applications can register with. I'm pretty certain Aura, for example, can do it.

(If I'm misunderstanding, I apologize. I've had a bunch of arguments with people about this already)


So it is handled by a browser, just not an external one. However, the way this is being handled is good practice for mobile applications, but as you said not good practice for desktop applications. I completely understand why it would be something that would be asked for though. I just followed convention for usual oAuth stuff, but I could certainly see if I can do it another way.
Sephira Galamore
Inner Beard Society
#67 - 2014-10-21 09:38:40 UTC
Chingy Chonga wrote:
Steve Ronuken wrote:
So the auth step is handled within the application, rather than forcing you out to your regular browser, then back in?

It's a bad practice, and not recommended for oauth. Users should be trained to always go and check the URL, and if that's not available, they should say 'lol, no' to using the app. Anything else is just asking for trouble.


The rest of it is fine though Smile The only real difference is handing it off, then using a custom protocol to bring it back in.

While it's not used in many place, the old XML api can do it (if you pass an install parameter, iirc). It then creates an eve:// protocol link, which applications can register with. I'm pretty certain Aura, for example, can do it.

(If I'm misunderstanding, I apologize. I've had a bunch of arguments with people about this already)


So it is handled by a browser, just not an external one. However, the way this is being handled is good practice for mobile applications, but as you said not good practice for desktop applications. I completely understand why it would be something that would be asked for though. I just followed convention for usual oAuth stuff, but I could certainly see if I can do it another way.

I found this: http://snipplr.com/view/49930/ - in the example "foo://" is registered as custom protocol associated with that app.

The open question is whether e.g. eve:// is a valid redirect_uri for the SSO, but that can be done by trial&error I guess.
Talos Katuma
Helion Production Labs
Independent Operators Consortium
#68 - 2014-10-30 18:38:43 UTC
If you didn't notice it yet, it's now life on production (including sso) :) I've to say that was quicker than expected.

https://developers.eveonline.com
CCP FoxFour
C C P
C C P Alliance
#69 - 2014-10-30 21:29:24 UTC
Talos Katuma wrote:
If you didn't notice it yet, it's now life on production (including sso) :) I've to say that was quicker than expected.

https://developers.eveonline.com


Shhhhh it's still a bit broken. Will hopefully announce it proper soon. :)

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

Trehan Crendraven
The Scope
Gallente Federation
#70 - 2014-10-31 10:19:57 UTC  |  Edited by: Trehan Crendraven
Talos Katuma wrote:
If you didn't notice it yet, it's now life on production (including sso) :) I've to say that was quicker than expected.

https://developers.eveonline.com



Does that mean that the SSO will check on the Tranquility servers ?

That would be awsome... Can't wait for it :)
Trehan Crendraven
The Scope
Gallente Federation
#71 - 2014-10-31 17:38:03 UTC
Jack Tronic
borkedLabs
#72 - 2014-10-31 18:49:32 UTC
Woo, now I can ditch API keys which are a gigantic security hole because of the API key dumps of hacked sites.
Bloemkoolsaus
Deep Core Mining Inc.
Caldari State
#73 - 2014-11-01 16:12:32 UTC
Quote:
Required Forms of Payment

To log in and create applications on the developer site we require you to have paid us money at some point and have a validated email address. Up until now the only form of payment that was considered was credit card. When signing into the developer site for the first time we will now check if you have paid us with any of our currently valid payment methods. This should help a lot for those of you in countries where credit cards are not very common.


Yeeee thank you guys! Big smileBig smile
Derrick Miles
Death Rabbit Ky Oneida
#74 - 2014-11-02 10:46:14 UTC
Quote:

GUIDELINES

1. Don't. Be. Bad.


So much for explicitly laid out rules...
CCP FoxFour
C C P
C C P Alliance
#75 - 2014-11-02 14:37:25 UTC
Derrick Miles wrote:
Quote:

GUIDELINES

1. Don't. Be. Bad.


So much for explicitly laid out rules...


It's a guideline, not a rule. The number of people that ask me on IRC/Twitter/Forums "can I do X, I know it's kind of a bad thing to do but..." is fairly large.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

SJ Astralana
Syncore
#76 - 2014-11-02 15:05:31 UTC
I've read as much as I can find, and I'm failing to find the relevance of some of what's been alluded to. I understand SSO ensuring that someone logging into forums or some other app are who they say they are -- that's fine. I see a greyed out reference to CREST on the developer site, with mention to accessing some user's zones. CREST right now is just game data, and every spreadsheet jockey consumes it. User data is consumed from the API, and again every spreadsheet jockey consumes it. No spreadsheet jockey is ever going to successfully integrate with oauth. So beyond what's been implemented, I fail to see the point of anything larger. Is there a strategic roadmap that's been published to clarify this?

Hyperdrive your production business: Eve Production Manager

Kali Izia
GoomWaffe
#77 - 2014-11-02 20:42:45 UTC
SJ Astralana wrote:
I've read as much as I can find, and I'm failing to find the relevance of some of what's been alluded to. I understand SSO ensuring that someone logging into forums or some other app are who they say they are -- that's fine. I see a greyed out reference to CREST on the developer site, with mention to accessing some user's zones. CREST right now is just game data, and every spreadsheet jockey consumes it. User data is consumed from the API, and again every spreadsheet jockey consumes it. No spreadsheet jockey is ever going to successfully integrate with oauth. So beyond what's been implemented, I fail to see the point of anything larger. Is there a strategic roadmap that's been published to clarify this?

The big thing about authenticated CREST is that it's read/write access directly to the EVE cluster.

Your spreadsheet probably isn't going to need to write anything back to EVE so the XML API may be enough for you.
However since CREST is actually running on the cluster and not just reading whatever data has been saved in the database, there's always the possibility that it could provide more useful data than the XML API is capable of (eg for things like PI that aren't always persisted to the database right away).

And it probably is very possible to get that data in a spreadsheet if you really needed it. You could potentially use an external tool to get an Oauth token and put that in your spreadsheet. How useful that would be depends on how the auth actually gets implemented, how long the tokens would be valid for etc.
SJ Astralana
Syncore
#78 - 2014-11-02 21:19:40 UTC
Kali Izia wrote:

The big thing about authenticated CREST is that it's read/write access directly to the EVE cluster.


What sorts of things will potentially be written? Again, a link to a roadmap would be nice.

Hyperdrive your production business: Eve Production Manager

Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#79 - 2014-11-02 21:45:00 UTC
SJ Astralana wrote:
Kali Izia wrote:

The big thing about authenticated CREST is that it's read/write access directly to the EVE cluster.


What sorts of things will potentially be written? Again, a link to a roadmap would be nice.



There is no roadmap, other than 'contacts, standings, maybe mail' at the moment.

However, what's possible is 'anything you can do with the eve client'. The restrictions are going to be coming from game design. So you probably won't see market manipulation (though it's technically possible) or industry jobs.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Max Kolonko
Caldari Provisions
Caldari State
#80 - 2014-11-02 22:35:40 UTC
Steve Ronuken wrote:
SJ Astralana wrote:
Kali Izia wrote:

The big thing about authenticated CREST is that it's read/write access directly to the EVE cluster.


What sorts of things will potentially be written? Again, a link to a roadmap would be nice.



There is no roadmap, other than 'contacts, standings, maybe mail' at the moment.

However, what's possible is 'anything you can do with the eve client'. The restrictions are going to be coming from game design. So you probably won't see market manipulation (though it's technically possible) or industry jobs.


What I would love to see is all those small things that corporate directors have to deal with opened for automation:
- setting standings
- sending mails
- paying cash to members
- creating contracts
- managing corporate market orders
- managing corporate fittings


Also from just a player point of view
- skill quee off-line :)