مشكلة WordPress اللعين "Reauth = 1" في مشكلة حلقة إعادة توجيه تسجيل الدخول إلى لوحة المشرف هذه المرة ، وأنا أشارك المعلومات حول كيفية إصلاحها ، في هذا المنشور. أنا لست خبيرًا في أمور Apache أو Linux أو WordPress ، ولكن المعلومات هنا يمكن أن تساعد الآخرين الذين صادفوا مواجهة نفس الموقف.
تسبب أحد تغييرات التكوين الثلاثة التي قمت بها في لوحة تحكم الاستضافة في حلقة تسجيل الدخول إلى مدير WordPress.
التغيير 1
أرفقت نطاقي بـ CloudFlare وقمت بتثبيت CloudFlare WordPress Plugin. عملت CDN بشكل جيد للغاية.
التغيير 2
في لوحة تحكم Plesk ، اتصلت بتثبيت WordPress الخاص بي. أظهر Plesk علامة حمراء بالقرب من تثبيت WordPress الخاص بي ، والذي عند النقر عليه ، طلب مني التحقق من أمان تثبيت WordPress الخاص بي. وقال انه:
عرض نتائج فحص الأمان لعمليات تثبيت WordPress المحددة. إذا لم تجتز بعض البيانات فحص الأمان ، يمكنك تحديد هذه البيانات في القائمة وتشديد أمانها.
أقوم بتحديد مفاتيح الأمان من القائمة والنقر فوق تأمين.
يقول وصف مفتاح الأمان:
يستخدم WordPress مفاتيح الأمان (AUTH_KEY و SECURE_AUTH_KEY و LOGGED_IN_KEY و NONCE_KEY) لضمان تشفير أفضل للمعلومات المخزنة في ملفات تعريف الارتباط الخاصة بالمستخدم ... إذا فشل التحقق من الأمان واخترت تأمين تثبيت WordPress ، فسيتم إنشاء مفاتيح أمان جيدة وإضافتها لتثبيت WordPress.
التغيير 3
بدأ nginx من إدارة الخدمات في بليسك.
حلقة تسجيل الدخول
في المرة القادمة عندما حاولت تسجيل الدخول إلى WordPress ، تمت إعادة توجيهه ببساطة إلى صفحة "Reauth = 1". إذا قمت عمداً بكتابة كلمة مرور خاطئة ، فهذا يعني أن كلمة المرور غير صحيحة. لذلك ، كانت عناصر المصادقة تعمل بشكل جيد ، ولكن لسبب ما تمت إعادة توجيهها إلى عنوان URL Reauth عند استخدام بيانات الاعتماد الصحيحة. إليك قائمة بالأشياء التي جربتها ، ولم يساعد أي منها (باستثناء رقم 15 أدناه).
- محو ذاكرة التخزين المؤقت لمتصفح الويب تمامًا ، وجرب متصفحات مختلفة.
- توقف nginx ، عند قراءته عن مشكلة التخزين المؤقت (nginx.conf)
- تم تعطيل المكون الإضافي CloudFlare عبر Plesk ، لأنه حطم ميزات WP Admin لبعض المستخدمين
- تعطيل جميع المكونات الإضافية ، وإعادة تشغيل الخادم
- الأمثل وإصلاح قاعدة البيانات عبر PhpMyAdmin
- تم التحقق من عنوان URL للموقع في جدول wp_options. كان صحيحا
- أذونات تم التحقق منها لملف wp-config و wp-admin و wp-يتضمن أدلة
- تمت إضافة WP_HOME و WP_SITEURL في wp-config.php
- تم إنشاء رموز مفاتيح SALT أو سر جديدة جديدة وإضافتها إلى wp-config.php
- تنشيط الموضوع السادس والعشرون
- نشر في منتديات WordPress ، ولا يوجد رد على الإطلاق
- استعادة موقعي من أحدث نسخة احتياطية من VaultPress
- وضع التطوير الممكّن في CloudFlare
- تعيين CloudFlare PageRule لتجاوز التخزين المؤقت لصفحات المسؤول (WP- *)
- فصل موقعي من CloudFlare
هناك العديد من الأشياء الأخرى التي قمت بها بالإضافة إلى ما سبق ، قد يكون بعضها تافهًا. كنت أفكر جديًا في هذه الخيارات:
- اطلب مساعدة CloudTech الاحترافية (عبر لوحة تحكم MT) مقابل 79 دولارًا ، ولكن الإصلاح غير مضمون.
- إعادة تعيين Plesk DV إلى الإعدادات الافتراضية. لكن استعادة كل شيء سيستغرق الكثير من الوقت.
- طلب استعادة الطوارئ ، مرة أخرى مقابل 79 دولارًا. تتم استعادة محتوى الموقع فقط ، وهو ما قمت به بالفعل من VaultPress.
- تجاهل الخادم وانتقل إلى Premium WordPress Hosting المُدار بواسطة نفس الموفر. وبذلك يستخدم إعدادات الخادم الافتراضية.
- إذا لم يساعد دعم MT ، فانتقل إلى DreamHost
كان هناك الكثير من الأفكار التي كانت تدور في ذهني وأضيع يوم كامل. بعد ساعات قليلة من فصل موقعي عن CloudFlare ، يطرح WordPress الآن رسالة خطأ مختلفة. تقول الآن "تم حظر ملفات تعريف الارتباط" على الرغم من تعيين كافة متصفحات الويب على قبول ملفات تعريف الارتباط.
تم إصلاحه في Atlast!
الخطوة 1:
في wp-config ، أزلت هذه السطور التي تحتوي على المفاتيح السرية:
تعريف ("AUTH_KEY" تعريف ("SECURE_AUTH_KEY" تعريف ("LOGGED_IN_KEY" تعريف ("NONCE_KEY" تعريف ("AUTH_SALT" تعريف ("SECURE_AUTH_SALT" تعريف ("LOGGED_IN_SALT" تعريف ("NONCE_SALT" الخطوة 2:
تم حفظ الملف بترميز UTF-8 (كان يظهر على هيئة ANSI). على الرغم من أن هذا قد لا يسبب المشكلة ... لكنني جربته.
أخيرًا ، تمكنت من تسجيل الدخول إلى لوحة إدارة WordPress. ثم أنشأت مفاتيح أمان جديدة ، وقمت بتسجيل الخروج من WordPress وقمت بتسجيل الدخول مرة أخرى. انها عملت!
ما سبب المشكلة في المقام الأول؟
في حين أن معظم المشاركات في الإنترنت تشير إلى المكون الإضافي CloudFlare الأخير ، لم يكن ذلك في حالتي. تخميني هو أن Plesk's Security Check (في التغيير رقم 2 أعلاه) كسرها ، فقط بعد إزالة المفاتيح السرية من wp-config.php سمح لي بتسجيل الدخول. بالطبع ، قمت بإنشاء مفاتيح أمان جديدة ، محدثة wp-config.php. ثم أعدت إرفاق موقعي بـ CloudFlare ومكّنت المكون الإضافي الخاص بها.
لحسن الحظ ، لم تظهر المشكلة حتى الآن!
المعنويات للقصة (قلت لنفسي): لا تلعب مع الإعدادات في Plesk إذا كنت لا تعرف ما تفعله. وقم بإجراء تغيير واحد في كل مرة ، وذلك أيضًا إذا كان ضروريًا للغاية ، حتى تعرف الإعداد الذي يسبب مشكلة. Linux / Apache ليس مثل Windows… إنهما أكثر تعقيدًا ، على الأقل بالنسبة لي. إذا ساعدك هذا المنشور أو كان لديك مدخلات إضافية لإصلاح هذه المشكلة ، فيرجى مشاركة أفكارك في قسم التعليقات أدناه.
