Is there an endpoint to check if a user is logged in

I need a URL that will return 200 for a logged in user and 401 or 403 if the user is not logged in.

If require_login is checked, every page does a 301 to the login page.

Is this a user request, i.e. using the current users session?

Or…

Is this an admin API request using an admin API key?

Yeah. It’s me not understanding the question I’m asking.

I’m trying to do an auth_request in NGINX to tell whether the request is coming from a user that’s logged in by querying an URL to see whether it gets a 200 response or not.

It’s occurring to me that doing that is not quite as simple as I’d hoped.

You could try /session/current.json

It will return 200 if authenticated and 404 if not.

Generally .json / API requests don’t redirect.

That seems promising. I’ll keep poking at it.

Many thanks!

Is there an easy way to do this from a different subdomain?

Example, the forum is at forum.example.com and the request is coming from example.com (either from the frontend or backend code).

Sure. You can make an API call from anywhere.

But this specific call needs to be done from the frontend, since it will use the session cookies sent by the browser to the forum.

The Discourse session cookie appears to be just for the subdomain, so would the cookie be accessible from the top-level domain? I see _forum_session on the Discourse subdomain but it doesn’t appear when visiting the TLD.

If the cookie were available on the top-level domain, I was thinking that it would also be passed to the backend, so the backend could forward it to Discourse, but I’m not sure.

Maybe it requires using Discourse as an SSO provider? If it isn’t known whether the user is logged in, then we could redirect through the SSO process to check. I’m currently setting it up on a test server to see if it would work.

Edit: my end goal is to generate a JWT with the user data from Discourse (only if logged in to Discourse) and pass it to Firebase. There is a Discourse server on the subdomain, an extra backend server that can perform additional logic, and an SPA that connects to Firebase if given a JWT.

If you want anything fancy like this you would need to implement your own CurrentUserProvider

Thanks, I just looked it up and found this other thread, so I’ll ask some more questions about it over there.

Edit: it looks like we can do what we need with Discourse as an SSO provider.

If you can do it with SSO I highly recommend you go that path vs a provider

Thanks, it looks like we can check if a user is logged in and then redirect through Discourse’s SSO route if not logged in. It seems to work well on my laptop. The user logout webhook from Discourse can then log them out of the other app.

Pourriez-vous s’il vous plaît expliquer un peu comment vérifier si un utilisateur est connecté à Discourse depuis un autre sous-domaine ? J’essaie de mettre en place un middleware d’authentification dans mes gestionnaires de routes (côté serveur) pour vérifier si la connexion SSO de l’utilisateur à Discourse est toujours valide.

J’essaie de mettre en œuvre presque la même chose pour une application web, mais je n’arrive pas à trouver comment vérifier si l’utilisateur est toujours connecté. (De préférence, connecté depuis le même navigateur actuellement utilisé pour envoyer la requête au serveur)
Merci !

Mon code n’est pas encore en ligne, mais si l’utilisateur est redirigé via un autre serveur (avec Discourse comme fournisseur SSO), une session existera sur ce serveur externe. J’ai créé une route là-bas, quelque chose comme /auth/is-authenticated, qui renvoie le statut de l’utilisateur. Elle sert principalement à masquer les boutons « Se connecter » lorsque l’utilisateur est déjà connecté. Lorsque l’utilisateur se déconnecte de Discourse, je pense qu’un webhook le déconnecte également de l’autre serveur. Je n’ai pas vérifié le code depuis un moment, mais je crois que c’est ainsi que je l’avais configuré.

Comment un serveur externe peut-il vérifier si le navigateur de l’utilisateur est toujours connecté à Discourse ? Je ne pense pas qu’un autre domaine puisse accéder aux cookies de Discourse définis après la connexion.

Mon objectif est de déconnecter l’utilisateur du serveur externe (qui n’est pas Discourse) si l’utilisateur s’est déconnecté de Discourse uniquement via le navigateur actif en cours. (Est-ce même possible ?)

Merci pour votre réponse.

Lorsque l’utilisateur se trouve sur l’application externe, il clique sur un bouton de connexion et est redirigé vers le flux du fournisseur SSO de Discourse, puis revient vers l’application externe. Cette application externe peut stocker une session avec les données de l’utilisateur. Lorsque l’utilisateur se déconnecte de Discourse, le webhook peut supprimer la session de l’application externe. Je ne suis pas certain, mais je pense que l’en-tête du webhook est X-Discourse-Event: user_logged_out.

Modification : la déconnexion depuis le site externe s’effectue via l’API Discourse.

Au lieu de demander à Discourse si un utilisateur est connecté, vous pouvez interroger l’application externe. Dans mon cas, cela sert simplement à des choses comme supprimer le bouton de connexion sur le site externe.

Je pourrai vérifier mon code plus tard. Je ne l’ai pas consulté depuis un moment, mais je pense qu’il faisait quelque chose de similaire.

Merci pour votre réponse ! Je l’apprécie vraiment.

Oui, c’est maintenant clair pour moi. La seule contrainte lors de la déconnexion via l’API est que l’utilisateur sera déconnecté de toutes ses sessions (sur tous les appareils, car l’API ne peut pas distinguer la session du navigateur actuel de celle des autres navigateurs connectés).