تمكنت من استخدام هذا لإنشاء نظام ربط حسابات لخادم Minecraft الخاص بي! اعتقدت أنني سأشارك كيف يبدو! كانت هذه المرة الأولى التي أعمل فيها مع Discourse SSO، لذلك ربما قمت بتعقيد كل شيء. ومع ذلك، فهو يعمل، وهذا هو الشيء الرئيسي.
مرحباً، لقد قمت بكل هذه الأمور بشكل صحيح. ولكن عندما لا يكون المستخدم مسجلاً الدخول إلى Discourse، فإنه سيظهر نافذة منبثقة لتسجيل دخول المستخدم. عندما أقوم بملء اسم المستخدم وكلمة المرور، فإنه لا يعيدني إلى عنوان URL للعودة. هل يمكنك مساعدتي؟
أفترض أن الـ nonce موجود لمنع هجمات إعادة التشغيل. قرأت عبر الإنترنت أن هجمات إعادة التشغيل غير ممكنة مع HTTPS، وهو ما أستخدمه. فهل ما زلت بحاجة إلى استخدام الـ nonce؟ أسأل لأنني لست متأكدًا من مكان تخزينه. هل من المنطقي تخزينه كملف تعريف ارتباط آمن ونص عادي في متصفح المستخدم؟ ثم قراءته من المتصفح مع حمولة الاستجابة؟
هذه المكتبة، المرتبطة من المنشور الأصلي GitHub - ArmedGuy/discourse_sso_node: npm package for Discourse SSO login features. لا تستخدم الـ nonce عند التحقق من صحة المستخدم.
نعم، ما زلت بحاجة إلى التحقق من صحة الـ nonce لأنه يمنع إعادة استخدام الحمولة التي يرسلها Discourse عند إعادة توجيه المستخدمين إلى موقعك.
على سبيل المثال، لنفترض أن موقعك يحتوي على بعض المحتوى خلف جدار دفع لا يمكن لأعضاء مجموعة subscribers في Discourse الوصول إليه إلا، وتستخدم حقل groups في الحمولة التي يرسلها Discourse إلى موقعك لعرض المحتوى المدفوع فقط لأعضاء مجموعة subscribers. إذا لم تقم بالتحقق من صحة الـ nonce، فيمكن للمستخدم الذي لم يعد في subscribers استخدام حمولة قديمة من وقت كان عضوًا لتسجيل الدخول إلى موقعك ورؤية المحتوى المدفوع.
من الأفضل تخزين الـ nonce في قاعدة بيانات مع تاريخ انتهاء صلاحية قصير وحذف الـ nonce من قاعدة البيانات بمجرد استخدامه. ومع ذلك، إذا لم تتمكن من استخدام قاعدة بيانات، فيمكنك استخدام ملف تعريف ارتباط لتخزين الـ nonce، ولكنك تحتاج إلى القيام ببعض الخطوات الإضافية لمنع إعادة استخدام الحمولة:
- إرفاق تاريخ انتهاء صلاحية بالـ nonce عند إنشائه، على سبيل المثال 10 دقائق من الوقت الحالي.
- توقيع ملف تعريف الارتباط بالكامل (nonce + تاريخ انتهاء الصلاحية) لمنع المستخدمين من تعديل الـ nonce و/أو تاريخ انتهاء الصلاحية.
- التحقق من توقيع ملف تعريف الارتباط والتأكد من أن الـ nonce لم تنته صلاحيته.
يجب أن يوفر لك ذلك حماية كافية ضد إعادة استخدام الحمولة. ضع في اعتبارك أنه يظل من الممكن تقنيًا إعادة استخدام حمولة، ولكن سيتم تقييدها بنافذة 10 دقائق بدلاً من الأبد.
حل أبسط لا يحتاج إلى ملف تعريف ارتباط هو تضمين تاريخ انتهاء الصلاحية في حقل مخصص في الحمولة التي تنشئها. بعد ذلك، عندما يقوم Discourse بإعادة توجيه المستخدمين إلى موقعك بحمولة، سيتم تضمين حقولك المخصصة ويمكنك استرداد تاريخ انتهاء الصلاحية والتحقق من أنه لم تنته صلاحيته. لتضمين حقل مخصص في الحمولة، تحتاج إلى تضمين حقل يبدأ بـ custom.، لذا ستبدو حمولتك كالتالي:
nonce=NONCE&return_sso_url=RETURN_URL&custom.expiration_date=TIMESTAMP
4 إعجابات
يمكنك أيضًا تخزين الـ nonce في الجلسة، مما سيمنع المستخدم من العبث بها أيضًا.
3 إعجابات
أعود إلى هذا الموضوع بعد سنوات
هل يمكن لأحد أن يخبرني ( @pfaffman أو @tobiaseigen أو @iamntz) بما يعيده موفر Discourse SSO؟ أعرف أنه يمكنني “تجربته ورؤيته” ولكنه سيكون من الجيد توثيقه. رمز عينة PHP الخاص بـ GitHub لا يذكر أي حقول أخرى حقًا.
من الناحية المثالية، سيقوم بإرسال نفس الحقول التي يرسلها Discourse عند استخدام البرنامج النصي الخارجي لـ SSO، مثل المعرف الخارجي، والبريد الإلكتروني، واسم المستخدم، والاسم، وصورة الرمز المميز وما إلى ذلك. حتى نتمكن من استيراد هذا وإنشاء مستخدم على جانبنا!
هل يخبر ووردبريس بالبريد الإلكتروني أيضًا؟
ماذا عن المجموعات والشارات وما إلى ذلك؟ هل يمكننا العثور على هذه المعلومات عن طريق إجراء استدعاءات REST؟
أخيرًا، ماذا عن الرسائل الخاصة للمستخدم والأشياء الأخرى؟ أعتقد أنه إذا كان Discord موفر oAuth ويسمح لتطبيقاتنا باستهلاك هذه الأشياء، فسيكون ذلك رائعًا.
عند محاولة تمكين Discourse Connect أحصل على هذا الخطأ:
enable_discourse_connect: لا يمكنك تمكين DiscourseConnect والدعوة فقط في نفس الوقت.
أي أفكار؟
أرى أنك طرحت نفس السؤال هنا: Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - #537. إذا كنت تحاول تكوين الإعداد enable discourse connect وليس الإعداد enable discourse connect provider، فإن الموضوع الآخر هو المكان الصحيح لطرح سؤالك.
الإعداد enable discourse connect provider مخصص عندما تريد استخدام موقع Discourse الخاص بك كموفر هوية لموقع آخر. الإعداد enable discourse connect مخصص عندما تريد تسجيل دخول المستخدمين إلى Discourse عبر موقع خارجي.
إعجاب واحد (1)
لقد طبقت الإجراء في بايثون لتطبيق Flask أقوم ببنائه. إليك بعض التعليمات البرمجية الأساسية لأي شخص يحتاجها. كانت الخطوات الموضحة في هذا الموضوع بسيطة جدًا في اتباعها ولكني لست متخصصًا في الأمان ، لذا إذا فاتني أي شيء ، فيرجى إخباري!
إعجابَين (2)
نحن نحاول التنفيذ باستخدام Discourse كموفر SSO وما لا نفهمه هو كيف يعرف Discourse أي مستخدم يحتاج إلى التحقق؟ لذا تقول التعليمات: “قم بإنشاء حمولة جديدة مع nonce وعنوان URL للإرجاع”. ولكن عندما تنشر هذا عبر fetch إلى Discourse، كيف يعرف Discourse أي مستخدم يجب التحقق منه لمعرفة ما إذا كان قد قام بتسجيل الدخول؟ آسف، إذا كان هذا يبدو كسؤال غبي، لكنني لا أستطيع فهم كيف يعمل هذا وقد عملت مع العديد من أنظمة المصادقة على مر السنين، لذا فأنا على دراية بها إلى حد ما. هل عنوان البريد الإلكتروني للمستخدم الذي نحاول التحقق من حالة تسجيل الدخول له، يحتاج إلى تضمينه في الحمولة المرسلة إلى Discourse؟ إذا كان الأمر كذلك، فما هو الهيكل الدقيق للحمولة التي يجب إرسالها إلى Discourse. إذا لم يكن الأمر كذلك، فما الذي يتحقق منه Discourse بالضبط مرة أخرى؟ افتراضي هو أننا نطلب من المستخدم بريده الإلكتروني من جانبنا، ثم نرسل الحمولة مع البريد الإلكتروني إلى Discourse لمعرفة ما إذا كان هذا المستخدم المحدد قد قام بتسجيل الدخول، ولكن هذا ليس ما تقوله التعليمات، لذا أنا مرتبك تمامًا. شكرًا على أي مساعدة.
لا مشكلة. لقد قمنا بحل هذه المسألة. كنا نعتقد أن عنوان URL الخاص بتسجيل الدخول الموحد (SSO) يحتاج إلى إرساله كطلب POST إلى مثيل Discourse ثم تلقي استجابة. الآن نرى أن هذا إعادة توجيه إلى Discourse، ثم يقوم Discourse بإعادة التوجيه مرة أخرى إلى موقعنا. لذلك، أصبح من الواضح الآن ما يجب فعله. آسفون على المنشور السابق.
3 إعجابات
للعلم/للفائدة: لقد قدمت طلب سحب (PR) للسماح بمعلمة prompt=none في طلب المصادقة. على غرار ميزة في بروتوكول OpenID Connect، يتيح هذا للمستهلك SSO التحقق مما إذا كان المستخدم/العميل قد قام بتسجيل الدخول بالفعل، دون إرساله إلى مربع حوار تسجيل الدخول إذا لم يكن كذلك.
لقد انتظر طلب السحب (PR) مراجعة نهائية من شخص ما في فريق Discourse لمدة 8 أسابيع تقريبًا؛ يبدو أن هذا وقت أطول بكثير مما أتوقع. 
7 إعجابات
مرحباً @mdoggydog - آسف على التأخير الطويل جداً هنا!
لقد قمت للتو بمراجعة ودمج طلب السحب - شكراً على المساهمة! 
3 إعجابات
رائع! شكراً لك، @david.
كما وعدت، قمت للتو بتحديث مقالة الويكي هنا لتضمين وصف للمعامل الجديد (والمعامل الجديد السابق logout، ولإصلاح بعض الأخطاء الإملائية/النحوية الطفيفة، ولإضافة قسم مراجع يوثق حمولة sso= كما أفهمها من خلال البحث في الكود المصدري).
إعجابَين (2)
أريد التوقف عن استخدام موقعنا الإلكتروني ليكون بمثابة SSO لـ Discourse واستخدام أدوات تسجيل الدخول المضمنة في Discourse بدلاً من ذلك للحد من الوصول إلى مواد معينة على موقعنا الإلكتروني.
أعتقد أن الأداة المناسبة للاستخدام هي: GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users
لم أجد أي تعليمات شاملة حول كيفية استخدامه.
هل يمكنني تثبيت ذلك في نفس قطرة DigitalOcean مثل موقع Discourse الخاص بنا، أم أحتاج إلى استضافته في مكان آخر؟
تعديل: تم تمييز سؤالي 
إعجاب واحد (1)
هل يمكن لأحد المساعدة في السؤال أعلاه؟ Use Discourse as an identity provider (SSO, DiscourseConnect) - #148 by alehandrof
أقوم بتعيين عنوان URL الذي يحتوي بنفسه على معلمة استعلام كـ return_sso_url:
http://localhost:7000/completeLogin?returnto=%2F
تبدو الحمولة التي أرسلها إلى /session/sso_provider كمعلمة sso كما يلي قبل ترميز base64:
nonce=ENIwf0bElViDu325dTd6&return_sso_url=http://localhost:7000/completeLogin?returnto=%2F
عنوان URL الذي يعيد Discourse التوجيه إليه فعليًا بعد المصادقة هو هذا (مع اختصار معلمات sso و sig):
http://localhost:7000/completeLogin?returnto=/\u0026sso=...\u0026sig=...
ما يفاجئني هنا هو أن سلسلة الاستعلام التي قمت بتعيينها لـ return_sso_url يبدو أنها تم فك ترميزها بواسطة شيء ما، لأنها تحتوي على returnto=/ بدلاً من returnto=%2F. القيمة return_sso_url التي أجدها داخل sso بعد فك ترميز base64 لها تحتوي أيضًا على شرطة مائلة بدلاً من %2F.
هل هذا ما يجب أن أتوقعه؟ (إذا كان الأمر كذلك، فلماذا؟) هل هذه مشكلة في Discourse؟
ما هو السبب في أن حمولة sso تحتوي على avatar_url بدلاً من avatar_template كما هو مُرجع في /u/{username}.json و /session/current.json؟
avatar_url غير موجود للمستخدمين الذين لم يقوموا بتعيين صورة رمزية، بينما يحتوي avatar_template على المسار leter_avatar_proxy المستخدم فعليًا في Discourse لعرض الصور الرمزية لهؤلاء المستخدمين، ويشير avatar_url إلى صورة الرمزية الخام بدلاً من صورة مُقاسة بالحجم المطلوب للمستخدمين الذين قاموا بتعيين صورة رمزية.
يبدو لي أن avatar_template هو ما يريده أي شخص ينوي استخدام معلومات الصورة الرمزية الموجودة في sso - ولكن بعد ذلك سيحتاج إلى إجراء طلب API إضافي للحصول عليه.
إعجابَين (2)
أنا أقوم حاليًا بتطبيق تسجيل الدخول الموحد (SSO) في تطبيقي، وتسجيل الدخول يعمل بشكل جيد جدًا حتى الآن، وتسجيل الخروج لا يعمل.
يقوم مثيل Discourse الخاص بي بإعادة التوجيه بشكل صحيح إلى عنوان URL للعودة بدون أي معلمة sso أو sig، ولكن عندما أفتح Discourse، لا يزال حسابي مسجلاً الدخول.
أي أفكار؟
أفترض أنك تستخدم إعداد موقع Discourse logout redirect لإعادة توجيه المستخدمين مرة أخرى إلى تطبيقك بعد تسجيل خروجهم من Discourse.
السبب المحتمل للمشكلة هو إذا تم تمكين إعداد login required على موقع Discourse الخاص بك. عند تمكين هذا الإعداد، سيقوم Discourse تلقائيًا بإعادة توجيه المستخدمين غير المصادق عليهم إلى موقع مزود SSO إذا انتقلوا مباشرة إلى موقع Discourse. هذا يعني أنه ما لم تقم بتسجيل خروج المستخدمين من تطبيقك عند إعادة توجيههم لأول مرة إلى عنوان URL logout redirect، فسيتم تسجيل دخولهم تلقائيًا إلى Discourse في المرة التالية التي يزورون فيها الموقع. يمكنك تأكيد هذا السلوك من خلال المرور بالعملية مع فتح مفتش المتصفح الخاص بك على علامة تبويب الشبكة الخاصة به.
في حال كان ذلك مفيدًا، إليك كيف يتعامل المكون الإضافي WP Discourse مع إعادة توجيه تسجيل الخروج من Discourse: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.
إعجابَين (2)