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.

Discourse にログインしているかどうかを、別のサブドメインからどのように確認できるか、少し詳しく教えていただけますか?私はサーバー側のルートハンドラーで認証ミドルウェアを実装し、ユーザーの Discourse への SSO ログイン状態がまだ有効かどうかを確認しようとしています。

私は Web アプリでほぼ同じことを実装しようとしていますが、ユーザーがまだログインしているかどうかを確認する方法がわかりません(できれば、現在サーバーにリクエストを送信しているのと同じブラウザからログインしていることを確認したいです)。
ありがとうございます!

私のコードはまだ公開されていませんが、ユーザーが別のサーバー(SSO プロバイダーとして Discourse を使用)を介してリダイレクトされる場合、その外部サーバーにセッションが存在します。そこで /auth/is-authenticated のようなルートを作成し、ユーザーのステータスを返すようにしています。これは主に、ユーザーが既にログインしている場合に「ログイン」ボタンを非表示にするためのものです。ユーザーが Discourse からログアウトすると、別のサーバーからもログアウトされるように、Webhook が機能していると思います。コードを確認していない期間が長いですが、私の設定はあのようになっていたはずです。

外部サーバーのルートは、ユーザーのブラウザがまだ Discourse にログインしているかどうかを確認できますか?別のドメインは、ログイン後に設定された Discourse のクッキーにアクセスできないと思います。

私の目的は、ユーザーが現在のアクティブなブラウザを使用して Discourse からログアウトした場合に、外部(Discourse 以外の)サーバーからユーザーをログアウトさせることです。(これは可能でしょうか?)

返信ありがとうございます。

ユーザーが外部アプリにいる際、ログインボタンをクリックすると、Discourse の SSO プロバイダーフローを経由して再び外部アプリに戻されます。その外部アプリは、ユーザーのデータを含むセッションを保持できます。ユーザーが Discourse からログアウトすると、Webhook を介して外部アプリのセッションを削除することも可能です。確信はありませんが、Webhook のヘッダーは X-Discourse-Event: user_logged_out だったと思います。

追記: 外部サイトからのログアウトは、Discourse API を使用して行います。

ユーザーが Discourse にログインしているかどうかを Discourse に問い合わせる代わりに、外部アプリに問い合わせても構いません。私のケースでは、外部サイトからログインボタンを非表示にするなどの用途です。

後でコードを再度確認できます。しばらく見ていませんが、おそらくそのような処理をしていたと思います。

返信ありがとうございます!本当に感謝しています。

はい、今では明確になりました。API を使用したログアウトにおける唯一の注意点として、ユーザーはすべてのセッション(すべてのデバイス上のセッション)からログアウトされてしまいます。これは、API が現在のブラウザのセッションと他のログイン中のブラウザのセッションを区別できないためです。