فشل تسجيل الدخول في موقع واحد فقط في نظام متعدد المواقع

الدعم
1

لدي موقع Discourse رئيسي واحد مع 6 مواقع فرعية إضافية مضافة إليه، لكل منها نطاق وقاعدة بيانات مميزة.

في البداية، قمت بنسخ قاعدة بيانات الموقع الرئيسي للحفاظ على الاتساق، وقد نجح الأمر مع المواقع الفرعية الخمسة الأخرى.

بالنسبة لموقع واحد فقط، كلما حاولت تسجيل الدخول:

  • إذا كان عبر OIDC، أحصل على خطأ “عذرًا، انتهت مهلة التفويض، أو قمت بتبديل المتصفحات. يرجى المحاولة مرة أخرى.” على شاشة فارغة.
  • إذا كان عبر اسم المستخدم/كلمة المرور، أحصل على خطأ “خطأ غير معروف” أعلى مربع اسم المستخدم/كلمة المرور.

لقد قمت حتى بنسخ قاعدة البيانات من موقع يعمل إلى الموقع الجديد، لكنه لا يعمل.

فيما يلي تكوين المواقع المتعددة، في حال كان ذلك مفيدًا.

oneexample:
  adapter: postgresql
  database: oneexample
  username: adminexample
  password: pwexample
  host: 192.168.1.1
  port: 5432
  pool: 25
  timeout: 5000
  db_id: 5
  host_names:
    - 1example.com

السبب الذي جعلني أختار “oneexample” و “1example” هو أن النطاق يحتوي على رقم في المقدمة. شكي الوحيد حتى الآن هو أن الرقم يسبب المشكلة، لأن نسخ قاعدة البيانات مرة أخرى إلى موقع يعمل بدون رقم في اسم النطاق يعمل بشكل جيد.

قد يقول البعض أنه يجب علي اختيار نطاق مختلف، لكن هذا النطاق مدفوع الثمن وباهظ الثمن، وأود أن أجعله يعمل.

لقد قمت بإزالة ملفات تعريف الارتباط للمتصفح، ومسحت سجلات تسجيل الدخول من قاعدة البيانات، وجربت أيضًا مع نطاق آخر بنفس قاعدة البيانات. كل شيء عمل بشكل جيد.

أحد الحلول المحتملة في ذهني الذي لم أجربه هو تغيير النطاق إلى نطاق فرعي، فقط لاستبدال الرقم في مقدمة عنوان النطاق، مثل:

ولكن مرة أخرى، هذا يضيع الغرض من دفع $$$ لهذا النطاق المميز.

هل أنظر في المكان الخطأ؟ هل يمكن أن يكون هناك أي حل يعمل؟

2

تمت المحاولة باستخدام أسماء المضيفين: xxx.1example.com أيضًا، ولكنها تعطي نفس الخطأ.

باستخدام نفس قاعدة البيانات، نجحت في المحاولة باستخدام عدد من عناوين URL بدون أرقام. يبدو أن الأمر يتعلق بمشكلة النطاق، ولكن ليس لدي أي فكرة أخرى.

3

من كتلة الموقع الخاصة بـ Nginx لدي،

proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Proto $scheme;

لقد قمت بإزالة السطر الأخير، حيث أن وظيفته تكرر السطرين الأولين. بطريقة ما، يبدو أن Discourse رأى أن تسجيل الدخول يأتي عبر http، بدلاً من https.

لقد أضفت أيضًا السطر التالي في app.yml، فقط للتأكد من أن Discourse يحاول تسجيل الدخول عبر https، وأخيرًا نجح الأمر.

  • DISCOURSE_FORCE_HTTPS: true
4

إذن، السؤال الرئيسي هو، كيف سار الأمر بالنسبة للمواقع الفرعية الخمسة الأخرى؟

5

لقد أوقعتني في هذا

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.