Checking whether a user is logged in on Discourse from another website

Support SSO

AI-generated summary

Checking if a User is Logged In on Discourse from Another Website

alehandrof wants to limit access to certain pages on their website based on whether someone is logged in on their private Discourse site.

alehandrof initially considered using the Discourse Auth Proxy, but simon suggested using DiscourseConnect (with Discourse as the auth provider) instead. This approach allows for checking if a user is logged in without requiring a login dialog.

simon provided a link to the DiscourseConnect documentation and highlighted the prompt parameter, which can be used to query if the user is logged in without directing them to a login dialog.

simon also shared examples of DiscourseConnect implementations in WordPress and Remix/React apps, which may be useful for others.

alehandrof confirmed that simon’s suggestion is the correct approach, although they are experiencing implementation issues due to the complexity of their custom CMS.

1

Hi folks,

I would like to limit access to certain pages on our website based on whether someone has a member account on our private Discourse. Presumably I would do that by checking by checking on those pages whether the user is logged in on Discourse at the time.

I think the right tool to use is: GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users

Is there any step-by-step documentation to using it?

Can I install that in the same DigitalOcean droplet as our Discourse site, or do I need to host it somewhere else?

2

Could I please get some help with using Discourse Auth Proxy?

I have Discourse on a Digital Ocean droplet, and a PHP website on a separate server.

3

You can do this with DiscourseConnect (with Discourse functioning as the auth provider): Use Discourse as an identity provider (SSO, DiscourseConnect).

I haven’t tried it yet, but the prompt parameter might be useful for your case:

  • prompt: If prompt=none, then the SSO request is treated as a “just checking” request. If the browser/device is already logged-in to Discourse, Discourse will return a successful SSO response bearing user authentication information, as usual. If the browser/device is not already logged-in, then Discourse will not ask the user to log in, and will immediately return an SSO response bearing the parameter failed=true instead of user information. This provides a mechanism to query if the user is logged-in, without ever directing the user to a login dialog if they are not.
4

This looks promising @simon. I hadn’t realized that DiscourseConnect could even function without enabling enable discourse connect but apparently it can! :thinking:

I’ll run some tests and report back – thanks for setting me on this track!

5

I wonder if using Discourse as the auth provider gets overlooked because of its name (DiscourseConnect). For example, just adding the term DiscourseConnect to a post on here creates a link to the topic about using an external site as the auth provider for Discourse. Using Discourse as an auth provider is one of my main justifications for having a Discourse site.

In case it helps, the WordPress plugin allows Discourse to function as an auth provider. The relevant code is here: wp-discourse/lib/sso-client at main · discourse/wp-discourse · GitHub. The code might be somewhat overly complicated.

Here’s a more straighforward implementation for a Remix/React app: discourse_remix_comments/app/routes/login.tsx at main · scossar/discourse_remix_comments · GitHub. If you ignore the typescript stuff, there’s not much to it.

6

@simon I just wanted to write back and thank you. I do think your suggestion earlier is the correct answer. I’ve had trouble implementing it on my site, but the issue seems to mostly be that it’s a half-custom CMS with a lot of rickety code getting in the way.