Issue with Edgeryders form

Well … a cookie is a cookie :slight_smile: You send it as a cookie (:cookie:), not as a POST or GET parameter. It is its own type of parameter, and gets sent with every request to the domain for which the browser has stored the cookie (here communities.edgeryders.eu). The SSO payload return value does not contain the cookie, instead it is directly received by the browser when logging a user in to communities.edgeryders.eu.

We have configured the server to allow cross-domain use of that authentication cookie. (Like the manual says: “This only works because we allow cross-domain use of the session cookie via the permit-api-cors plugin.”) So you only have to care about CORS whitelisting and doing a successful SSO login, and the system should care for the rest.

Here’s how the process works as a whole:

  1. Get your site’s domain added to “CORS allowed origins” on communities.edgeryders.eu.

  2. Initiate a SSO authentication in your JS application, via communities.edgeryders.eu.

  3. During SSO login, the user has to enter their username and password on communities.edgeryders.eu. As a result, they get the authentication cookie served from that site. Their browser stores it for domain communities.edgeryders.eu, giving them an active session on communities.edgeryders.eu (in addition to the SSO session on other sites via SSO login).

  4. From your JS application, send a request to https://communities.edgeryders.eu/multisite_account_api_key.json.

  5. Since there exists a cookie for communities.edgeryders.eu, the browser sends it together with the request automatically.

  6. That cookie authenticates your script’s request to multisite_account_api_key.json and the API call should be successful.

  7. The API call returns the user’s Admin API key for the requested Discourse forum(s) and can use that to access them from your JS application under the user’s account.

If that does not work, let me know. We tested and confirmed that cross-domain use of the cookie is possible.

Finally, here’s a way to get an idea what this cookie actually looks like (though no need to know, as it should be managed automatically): you log in as your normal user @owen to communities.edgeryders.eu and then analyze what the browser sends for authentication, and how:

  1. In the Chrome web developer tools, go to “Storage → Cookies” and see what cookies are there in logged-in state.

  2. Delete the cookies one after the other to find out which ones are essential for being logged in.

  3. You will find that the following cookie is the only essential one (here with a fake value, but it looks like this):

    _t:"d1afe7345cd1f6389a0d2ab7792569"
    
1 Like