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

Development

AI-generated summary

The discussion revolves around checking if a user is logged in to Discourse from another subdomain. pfaffman initially asks for an endpoint to check if a user is logged in, which DeanMarkTaylor suggests using /session/current.json for. However, this approach may not work across subdomains.

j127 shares their goal of generating a JWT with user data from Discourse and passing it to Firebase. They explore using Discourse as an SSO provider, which sam recommends instead of implementing a custom CurrentUserProvider.

j127 successfully implements the SSO solution, which involves redirecting through Discourse’s SSO route if not logged in. They also use the user logout webhook from Discourse to log users out of the other app.

BunnyMan asks for clarification on how to check if a user is logged in to Discourse from another subdomain. j127 explains their approach, which involves storing a session with user data in an external server and using a route to check the user’s status. However, BunnyMan points out that this method may not work due to cookie restrictions across domains.

j127 further explains their solution, which involves using the Discourse API to log users out of the external app when they log out of Discourse. However, BunnyMan notes that this approach logs users out of all sessions, not just the current browser session.

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

Discourse에 로그인된 사용자인지 확인하는 방법에 대해 좀 더 설명해 주실 수 있을까요? 서버의 라우트 핸들러에 인증 미들웨어를 구현하여, 사용자가 Discourse에 SSO로 로그인한 상태가 여전히 유효한지 확인하려고 합니다.

웹 앱에 대해 거의 동일한 작업을 구현하려 하고 있지만, 사용자가 여전히 로그인 상태인지 확인하는 방법을 찾지 못하고 있습니다. (가능하다면, 현재 서버로 요청을 보내는 데 사용 중인 동일한 브라우저에서 로그인된 상태인지 확인하는 것이 좋습니다)
감사합니다!

15

해당 코드는 아직 배포되지 않았지만, 사용자가 다른 서버를 통해 리디렉션되는 경우(이때 Discourse가 SSO 제공자로 사용됨) 해당 외부 서버에 세션이 존재하게 됩니다. 저는 그곳에 /auth/is-authenticated와 같은 라우트를 만들어 사용자의 인증 상태를 반환하도록 했습니다. 이 라우트는 주로 이미 로그인된 상태일 때 “로그인” 버튼을 제거하기 위해 존재합니다. 사용자가 Discourse에서 로그아웃하면 웹훅이 다른 서버에서도 로그아웃 처리를 한다고 생각합니다. 코드를 한동안 확인하지 않아 정확한 것은 아니지만, 그렇게 설정해 두었습니다.

16

외부 서버가 라우트를 통해 사용자의 브라우저가 여전히 Discourse에 로그인되어 있는지 확인할 수 있을까요? 로그인 후 설정된 Discourse 쿠키에 다른 도메인이 접근할 수조차 없다고 생각합니다.

제 목표는 사용자가 현재 활성화된 브라우저로만 Discourse에서 로그아웃한 경우, 외부(비-Discourse) 서버에서도 해당 사용자를 로그아웃하는 것입니다. (이것이 가능한가요?)

답변 주셔서 감사합니다.

17

사용자가 외부 앱에 있을 때 로그인 버튼을 클릭하면 Discourse의 SSO 제공자 플로우를 거쳐 다시 외부 앱으로 돌아옵니다. 이 외부 앱은 사용자 데이터를 포함한 세션을 저장할 수 있습니다. 사용자가 Discourse에서 로그아웃하면 웹훅을 통해 외부 앱의 세션을 삭제할 수 있습니다. 확실하지는 않지만, 웹훅 헤더는 X-Discourse-Event: user_logged_out이라고 생각합니다.

수정: 외부 사이트에서 로그아웃하는 것은 Discourse API를 통해 수행됩니다.

Discourse에 사용자가 로그인되어 있는지 묻는 대신, 외부 앱에 물어볼 수 있습니다. 제 경우, 외부 사이트에서 로그인 버튼을 제거하는 등의 용도로만 사용하고 있습니다.

나중에 제 코드를 다시 확인해 볼 수 있습니다. 오랫동안 코드를 보지 못했지만, 아마도 그런 방식으로 동작했을 것 같습니다.

18

답변 감사합니다! 정말 감사드립니다.

이제 명확해졌습니다. 다만 API를 통해 로그아웃할 때 주의할 점은, 사용자가 모든 세션(모든 기기)에서 로그아웃된다는 것입니다. API는 현재 브라우저 세션과 다른 로그인된 브라우저를 구별할 수 없기 때문입니다.