Setting the session token '_t' on the entire domain, not just my subdomain

Matt,

I was all set to object to you, but I think I finally get it. However, I’m going to go through this just to make sure I finally (or really) understand this, (and to leave this as a historic record of my ignorance/learning that others might learn as well).

I was going to object to this statement:
Discourse looks at the cookie that it gets sent

and say, “but I didn’t set a cookie”. But, now I finally think I’m getting what you were trying to tell me:

  1. a user goes to the forum.wordadodplicus.com site (dicourse) and registers. Discourse sets both the _t (persistent) and the _forum_session (session) tokens.
  2. the user goes to my main site (non-discourse) but no discourse cookies come through – they can’t.
  3. my rules detect the lack of my cookies (not discourse’s)
  4. because of this, my process does a 302 (or 301) to DISCOURSE_ROOT_URL/session/sso_provider as per this discussion: Using Discourse as a SSO provider
  5. this redirection sends the discourse _t and _s cookies (along with all the other payload info) and Discourse sends user information back to my process
  6. I set my own cookie, indicating that we don’t need to redirect to Discourse SSO API, if the user comes back again (I could make it a session cookie, or a persistent cookie, depending on what I might implement in my own session-store/database with the returned information)

You said all this before in your earlier post:

The main site will redirect the browser to the forum for the auth check, the forum will validate the cookies as being correct, and then automatically redirect back to the right place on the main site,

but I was too heads-down to read your reply properly, especially the phrase:

the forum will validate the cookies as being correct.

thanks again,
daniel

5 Likes