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

مطور
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

عندما يكون المستخدم في التطبيق الخارجي، ينقر على زر تسجيل الدخول ويتم توجيهه عبر تدفق مزود SSO الخاص بـ Discourse، ثم يعود إلى التطبيق الخارجي. يمكن لهذا التطبيق الخارجي تخزين جلسة عمل تحتوي على بيانات المستخدم. عند تسجيل خروج المستخدم من Discourse، يمكن للويب هوك حذف جلسة عمل التطبيق الخارجي. لست متأكدًا تمامًا، لكن أعتقد أن رأس الويب هوك هو X-Discourse-Event: user_logged_out.

تعديل: يتم تسجيل الخروج من الموقع الخارجي باستخدام واجهة برمجة تطبيقات Discourse.

بدلاً من سؤال Discourse عما إذا كان المستخدم مسجلاً للدخول، يمكنك سؤال التطبيق الخارجي. في حالتي، يُستخدم ذلك فقط لأشياء مثل إزالة زر تسجيل الدخول من الموقع الخارجي.

يمكنني التحقق من كودي لاحقًا. لم ألقِ نظرة عليه منذ فترة، لكن أعتقد أنه قام بشيء مشابه لذلك.

18

شكرًا لك على الرد! نقدر ذلك حقًا.

نعم، أصبح الأمر واضحًا لي الآن. العيب الوحيد في تسجيل الخروج عبر واجهة برمجة التطبيقات هو أن المستخدم سيتم تسجيل خروجه من جميع الجلسات (على جميع الأجهزة، حيث لا تستطيع الواجهة التمييز بين جلسة المتصفح الحالية وسessions المتصفحات الأخرى التي تم تسجيل الدخول إليها).