لا يمكن تسجيل الدخول بعد استعادة نسخة احتياطية من Discourse على خادم جديد

مرحباً،

لقد استعدت نسخة احتياطية من Discourse على آلة افتراضية جديدة.
يبدو أن عملية الاستعادة نفسها قد نجحت. أرى واجهة المستخدم الرسومية الصحيحة عند البدء.

عند محاولة تسجيل الدخول، أواجه خطأ غير معروف:

Processing by UsersController#create as */*
  Parameters: {"name"=>"Istvan XXXXXXX", "email"=>"istvan.XXXXXXXX@mailbox.org", "password"=>"[FILTERED]", "username"
=>"Istvan", "password_confirmation"=>"[FILTERED]", "challenge"=>"6662a14f4549a786ed0f37XXXXXX", "timezone"=>"Eur
ope/Berlin"}
Filter chain halted as :respond_to_suspicious_request rendered or redirected
Completed 200 OK in 3ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 1007)
Started POST "/login" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by StaticController#enter as HTML
  Parameters: {"username"=>"Istvan", "password"=>"[FILTERED]", "redirect"=>"/u/account-created"}
Redirected to http://discourse.XXXXXXXXX/u/account-created
Completed 302 Found in 2ms (ActiveRecord: 0.0ms | Allocations: 512)
Started GET "/u/account-created" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by UsersController#account_created as HTML
  Rendered default/empty.html.erb within layouts/application (Duration: 0.1ms | Allocations: 11)
  Rendered layout layouts/application.html.erb (Duration: 60.6ms | Allocations: 36879)
Completed 200 OK in 81ms (Views: 62.1ms | ActiveRecord: 0.0ms | Allocations: 39906)
Started GET "/session/csrf" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 4ms (Views: 2.0ms | Allocations: 602)
Started POST "/session" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"Istvan", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Berlin"
}
Can't verify CSRF token authenticity.
  Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 5ms (Views: 0.7ms | Allocations: 897)

هل لديك أي فكرة حول كيفية حل هذه المشكلة؟

مع أطيب التحيات،

إ.

جرب إعادة تعيين كلمة المرور

لقد جربته، لكنه لا يعمل مع ذلك …

أعتقد أن رسائل البريد الإلكتروني تم تعطيلها في التثبيت القديم (لقد استعدت نسخة احتياطية منه).

أنا.

حاول التحقق مما إذا كان force_https مفعّلاً باستخدام وحدة التحكم

SiteSetting.force_https

إذا كانت قيمته false، فعيّنها إلى true

SiteSetting.force_https = true

هل تقصد داخل حاوية Docker أم في سطر أوامر VM؟

داخل Docker. قم بذلك في جهازك الافتراضي (VM)

cd /var/discourse/
./launcher enter app
rails c

شكرًا لك، ومع ذلك كانت القيمة بالفعل “صحيحة”:

image

ربما يجب تعيينها على “خطأ” (لأنني لا أملك شهادة) أو يجب استخدام النطاق الصحيح. (فهي لم تُعدّ بعد عبر CNAME)

لم يتم تفعيل HTTPS في ملف YAML.

لماذا لا؟ تمنحك Let’s Encrypt شهادة مجانًا.

إذا كنت تحاول استخدام عنوان IP دون اسم مضيف، فهذه هي مشكلتك. يجب أن تستخدم اسم مضيف.

إذا لم تكن تستخدم HTTPS، فيجب بالفعل تعيينه إلى false.

نطاق النظام “المنتجاتي” هو “https://deinbalkonnetz.de” (مستضاف على @discourse). لقد قمنا بنقله إلى جهاز افتراضي داخلي لا يزال يحمل النطاق “discourse.itas-karlsruhe.de”. لا يزال هذا النطاق (بدون دعم HTTPS) مستخدمًا في ملف app.yml.

ما هو الترتيب الصحيح لنقل Discourse؟

#1 إعادة توجيه النطاق الإنتاجي إلى الجهاز الافتراضي؟
#2 تغيير ملف app.yml إلى النطاق النهائي وتفعيل lets encrypt في نفس الوقت؟

يرجى التأكيد!

شكرًا لك.

إ.

إذا كنت تغادر استضافة discourse.org، فيجب عليك أولاً إلغاء اشتراكك حتى تُدرج التحميلات في النسخة الاحتياطية الخاصة بك. وإلا، فإن النسخة الاحتياطية ستشير فقط إلى التحميلات الموجودة على خوادم S3/CDN الخاصة بهم.

أوصي بإجراء الاختبارات على خادم يحتوي على عنوان IP عام، أو على الأقل خادم يحتوي على شهادة HTTPS صالحة (وهو أمر أصعب في الإعداد على عنوان IP خاص).

عندما تكون مستعدًا للانتقال، ستحتاج إلى تغيير إعدادات DNS لخادمك وإعادة البناء للحصول على شهادة Let’s Encrypt، لذا ستبقى في حالة انتظار لفترة قصيرة حتى تنتشر تحديثات DNS.

حسناً، شكراً جزيلاً لك.

إذا كنت تغادر استضافة discourse.org، فيجب عليك أولاً إلغاء اشتراكك لضمان تضمين الملفات المرفوعة في نسخة الاحتياطية الخاصة بك. وإلا، فإن نسخة الاحتياطية ستشير فقط إلى الملفات المرفوعة المخزنة على S3/CDN الخاصة بهم.

لقد طلبت نسخة احتياطية جديدة …

أوصي بإجراء اختباراتك على خادم يحتوي على عنوان IP عام، أو على الأقل خادم يحتوي على شهادة HTTPS صالحة (وهو أمر أصعب في الإعداد على عنوان IP خاص).

سأقوم بتعطيل HTTPS في “rail c” فقط لتمكين تسجيل الدخول. بعد تسجيل الدخول، سأتحقق مما إذا كان إضافة letsencrypt مفعّلاً (أو هل يجب تفعيله عبر app.yml)؟ إذا كان مفعّلاً، فسأقوم بتفعيل HTTPS للنطاق المؤقت. وإذا سار كل شيء على ما يرام، سنوجه النطاق النهائي إلى الآلة الافتراضية (VM) ونعيد بناء التطبيق باستخدام هذا النطاق.

أعتقد أن هذه خطة عمل مناسبة… أليس كذلك؟

مرحباً،

بعد تعطيل https عبر SiteSetting.force_https = false، أصبح الموقع قابلاً للوصول وتمكنت من تسجيل الدخول كمسؤول للموقع.

لقد قمت بإعداد let’s encrypt وفقًا للخطوات الموصوفة:
(Set up HTTPS support with Let's Encrypt)

بعد إعادة بناء الموقع، لم ينجح أي شيء، ولم يكن بإمكان الوصول إلى الموقع عبر المتصفح…

هل توجد طريقة للتحقق مما حدث خطأ؟

مع خالص التحية،

أ.