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

Desarrollador
1

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.

2

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

Or…

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

3

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.

4

You could try /session/current.json

It will return 200 if authenticated and 404 if not.

Generally .json / API requests don’t redirect.

5

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

Many thanks!

6

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).

7

Sure. You can make an API call from anywhere.

8

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.

9

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.

10

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

11

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.

12

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

13

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.

14

¿Podrías explicarme un poco cómo podemos verificar si un usuario ha iniciado sesión en Discourse desde otro subdominio? Estoy intentando implementar un middleware de autenticación en mis manejadores de rutas (en el servidor) para comprobar si la sesión SSO del usuario en Discourse sigue siendo válida.

Estoy intentando implementar casi lo mismo para una aplicación web, pero no logro averiguar cómo verificar si el usuario sigue conectado. (Preferiblemente que haya iniciado sesión desde el mismo navegador que se está utilizando actualmente para enviar la solicitud al servidor).
¡Gracias!

15

Mi código para esto aún no está en vivo, pero si el usuario es redirigido a través de otro servidor (con Discourse como proveedor de SSO), entonces habrá una sesión en ese servidor externo. Creé una ruta allí, algo como /auth/is-authenticated, que devuelve el estado del usuario. Básicamente está ahí para eliminar los botones de “iniciar sesión” cuando el usuario ya ha iniciado sesión. Cuando el usuario cierra sesión en Discourse, creo que un webhook lo cierra sesión en el otro servidor. No he revisado el código desde hace un tiempo, pero creo que así es como lo configuré.

16

¿Cómo puede una ruta de un servidor externo verificar si el navegador del usuario sigue conectado a Discourse? No creo que otro dominio pueda siquiera acceder a las cookies de Discourse establecidas después del inicio de sesión.

Mi objetivo es cerrar la sesión del usuario en el servidor externo (no Discourse) si el usuario cerró la sesión en Discourse usando solo el navegador activo actual. (¿Es incluso posible?)

Gracias por la respuesta.

17

Cuando el usuario está en la aplicación externa, hace clic en un botón de inicio de sesión y es redirigido a través del flujo del proveedor SSO de Discourse, y luego de vuelta a la aplicación externa. Esa aplicación externa puede almacenar una sesión con los datos del usuario. Cuando el usuario cierra sesión en Discourse, el webhook puede eliminar la sesión de la aplicación externa. No estoy seguro, pero creo que el encabezado del webhook es X-Discourse-Event: user_logged_out.

Edición: el cierre de sesión desde el sitio externo se realiza mediante la API de Discourse.

En lugar de preguntar a Discourse si un usuario ha iniciado sesión, puedes consultar la aplicación externa. En mi caso, esto sirve para cosas como eliminar el botón de inicio de sesión en el sitio externo.

Puedo verificar mi código más tarde. No lo he revisado en un tiempo, pero creo que hacía algo así.

18

¡Gracias por la respuesta! Lo aprecio mucho.

Sí, ahora me está claro. La única salvedad al cerrar sesión con la API es que el usuario será desconectado de todas las sesiones (en todos los dispositivos, ya que la API no puede distinguir entre la sesión del navegador actual y otros navegadores con sesión iniciada).