Discourse as SSO source of authority for Wordpress

(Sam Saffron) #9

Its trivial, you just enable the setting “enable sso provider” and plug in your password.

(Kane York) #10

I think he was talking about the consumer side.

(James Khan) #11

I’m writing a resource API for jmonkeyengine.org using discourse as the primary account system, and it’s entirely possible right now. The implementation (in java) is written here:

I’m not entirely sure if it would help to solve your issue, but if the response were to return the session string upon login as opposed to just setting the cookie, that would at least give the programmer something to work with (stored session comparison). Then again, you could do that by decrypting the cookie (base64 iirc). So… there’s something there to work with already, albeit a bit of a hack.

Use Discourse Authentication on Dokuwiki
(Kane York) #12

Why aren’t you using the enable sso provider site setting? Then you can just do SSO with the roles reversed. Look @ the discourse code for SSO (current user provider stuff) for how to do that.

(James Khan) #13

Lack of documentation is the only reason, or at least that was the case when I first started the implementation… And when I looked at the code at that point in time, it appeared to be half-implemented.

(Daniel Brief) #14

@riking, @sam can you give a little more detail for us Newbies? I looked at Official Single-Sign-On for Discourse (sso) and tried to reverse the flow, starting with calling my discourse server where the example called the external server, but that doesn’t work (I get a 404 on /discourse/sso?). So it’s a little more than literally reversing the roles… If I need to RTFM, please point me to the right place(s).
Any help would be much appreciated!

(Kane York) #15

The URL is /session/sso_provider . Fill in the SSO_secret like normal.

(Daniel Brief) #16

Getting closer - it redirects to /login, I see a request to get /session/csrf which looks OK and then I type in name and password, hit enter and the browser does a POST to /session with my login and pw in the data and a X-CSRF-Token header with the value session/csrf returned, but I get a 500 - Internal Server Error and the dialog shows “Unknown error”. If I type in an incorrect password then /session returns a 200 with the error message “Incorrect username, email or password”. If I login with Facebook then it works.

(Daniel Brief) #17

@riking - another clue - in the log I get the following stack trace:

Started POST "/session" for at 2015-03-25 11:48:12 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"daniel@mysite.com", "password"=>"[FILTERED]"}
Completed 500 Internal Server Error in 332ms

RuntimeError (sso_url not implemented on class, be sure to set it on instance):
  lib/single_sign_on.rb:16:in `sso_url'
  lib/single_sign_on.rb:63:in `sso_url'
  lib/single_sign_on.rb:77:in `to_url'
  app/controllers/session_controller.rb:32:in `sso_provider'
  app/controllers/session_controller.rb:250:in `login'
  app/controllers/session_controller.rb:158:in `create'
  config/initializers/08-rack-cors.rb:11:in `call'
  lib/middleware/anonymous_cache.rb:123:in `call'
  config/initializers/quiet_logger.rb:10:in `call_with_quiet_assets'
  config/initializers/silence_logger.rb:26:in `call'
  lib/middleware/request_tracker.rb:70:in `call'
  lib/scheduler/defer.rb:85:in `process_client'
  lib/middleware/unicorn_oobgc.rb:95:in `process_client'

I get that sso_url is not defined, but I’m not clear where it should be defined. I tried putting a page on my main site in the “sso url” field in the login settings, but that doesn’t seem to have any effect. Should I add it to the request that passed the nonce (&sso_url=http…? )? Some other way?

(Jens Maier) #18

Uh, this looks like a bug…

Shouldn’t that be DiscourseSingleSignOn instead of SingleSignOn in line 24?

(Sam Saffron) #19

I don’t think so … its independent to other SSO on the site. We have provider working fine for us here. I think this is happening cause @danb is not sending in a return_sso_url, which 100% required for this use case.

(Jeff Atwood) #20

If it is 100% required we need to improve our error messaging to make that clear… otherwise we’ll get future support requests for this.

(Sam Saffron) #21

Sure, we also need to properly document this feature.

(Jens Maier) #22

Then where would the sso instance get its @sso_url from? It’s never set during SingleSignOn::parse or anywhere else by the time the code calls #to_url. In fact, in this regard the whole SingleSignOn class is abstract because it contains no code that would ever set @sso_url but will inevitably fail without it being set…

(Dammit, I keep replying to the wrong posts. Meant to reply to @sam.)

(Jeff Atwood) #23

You can change who you reply to before post submission by clicking reply on the post you wanted to originally reply to while the editor is still up, and before the post is submitted. After submission, it’s just set.

(Jens Maier) #24

I know, I’m just not reading the “Replying to post #{number} by #{other user}” message anymore and end up tripping over my own mousebutton finger…

On any other forum, I’d delete the post and resubmit it, but without ninja-deletes that would cause even more noise. :frowning:

(Sam Saffron) #25

Not really abstract … see:

as long as to_url gets a base url all is good.

(Jens Maier) #26

Oooh, ok, yes, and return_sso_url is set via the request… that makes sense. :sweat_smile:

(Daniel Brief) #27

OK, added return_sso_url and added Access-Allow-Control-Origin permission for my Discourse site to my main site and login is now working :smiley:
I’m still trying to figure out:
How can my front-end know when login is completed (poll my server to see if return_sso_url has been run?)
After FB login (I assume also Google/Twitter/Github etc,) or canceling login shouldn’t return_sso_url get called? How can I tell whether login succeeded or failed?


(Sam Saffron) #28

you would need to handle that on your side, once we redirect you back then you know you are logged in.