FYI: I found a solution for George as well.  As a reminder, this was being
able to log George in automatically to Discourse when he is already logged
in to  There is a specific "route" we can send George to
via Discourse to have him automatically log him in:  /session/sso.  So, in
our example, the URL would be
This will prompt Discourse to automatically start the sso handshake, and
automatically log George in (because, as indicated in the User Story,
George is already logged in to

If George were NOT logged in, then this would prompt George to log in.
What this means, then, is that if there is anonymous user who just wants to
look around (which I believe is something we want to do), routing everyone
directly to session/sso would block anonymous users from ever accessing
Discourse (the sso logic would force a login).  When we build the links to
send someone to Discourse from the site, we need to ensure
that we're applying logic to determine whether or not the user is already
logged in (using the maybeAuth function) to determine which link to make
available to them (/ or /session/sso).

One additional Noteworthy point:  The data that we can send to Discourse to
automatically populate expands beyond what we have in our current User
table.  Username, Full Name, and Bio are three fields we currently do not
have set up.  We may want to note someplace when it comes time to expanding
on the user info that we'll want to ensure these three fields are available
and that we update Handler/Discourse.hs to send those fields when they
exist.  I don't think it's worthwhile to do right this moment, as that will
entail creating a User Settings page that we don't currently have, and I'm
not sure how MVP that type of update would be at the moment (I
unfortunately cannot typically make the weekly meetings, so...).

Any additional questions, let me know.

- Jason

On Wed, Dec 7, 2016 at 7:14 AM, Jason Harrer <> wrote:

> For those who may not be watching our Github repo, a patch was submitted
> yesterday on Github to fix the redirect problem.  I downloaded the patch to
> the Discourse SSO branch I've been working with, and Sidney is now able to
> login properly the first time she clicks on "Log In" from Discourse:  She
> gets redirected to the login, enters her credentials, clicks
> "Log in", and *ultimately* gets redirected back to Discourse logged in
> (technically, a bit more in depth than that, but that's ok).
> There were concerns presented that this broke things previously, which is
> why it was changed.  Based on what we have now, it appears to be working.
> I'll test a little bit more manually for now, but ultimately, we need some
> automated tests written to make sure this works.  I have not learned how to
> write unit tests, so if someone else is up for the challenge OR if someone
> wants to spend time showing me how to do so, I would definitely appreciate
> the help.
> If someone can get me a patch for the unit tests, I can bundle up all the
> various patches into one MR back to and help Salt get
> this up and running.
> Thanks!!
> - Jason
> On Tue, Dec 6, 2016 at 2:11 PM, Stephen Michel <>
> wrote:
>> On Tue, Dec 6, 2016 at 12:30 PM, fr33domlover <>
>> wrote:
>>> So, Bryan, waiting for your input on this. For now, I suppose it's not
>>> super
>>> critical, but it definitely will annoy and confuse users once the
>>> Discourse
>>> instance starts getting filled with people and messages (or is it
>>> alreday? I
>>> didn't check).
>>> -- fr33
>> When last I heard, the plan was to completely wipe the current Discourse
>> instance and start clean with SSO. To that end, I believe the only people
>> with accounts on Discourse are team members who have been manually invited.
>> I'm not the most in the loop, so take this a grain of salt.
>> ~Stephen
>> _______________________________________________
>> Dev mailing list
Dev mailing list

Reply via email to