Grav-plugin-admin: رمز الأمان غير صالح

هل كانت قضية لمرة واحدة؟ هل يمكنك تسجيل الدخول مرة أخرى على الإطلاق؟

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

هل هناك أي فرصة للاختبار باستخدام محلول WAMP آخر؟ ماذا عن Uniform Server (http://www.uniformserver.com/) لأنه لا يغزو مجلد البرامج الخاصة بك؟

أو MAMP؟

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

MAMP ليست ذات صلة ، تحدث مشكلة رمز الأمان أيضًا في بيئة الإنتاج الخاصة بي (استضافة الويب). لا يمكنني كتابة صفحة معيارية ، فهي تستمر في تسجيل خروجي. انه مزعج.

يبدو الأمر غريبًا على خادم الويب - هل يمكنك محاولة الوصول إلى الصفحة في وضع التصفح المتخفي / الخاص ، أو مسح ملفات تعريف الارتباط / ذاكرة التخزين المؤقت ، للتأكد من عدم وجود تعارض مع بيئتك المحلية؟

أحصل على هذا في كل شكل في أشكال مظهر g5_hydrogren:

403 Forbidden

Oops, Invalid security token; please reload the page and try again..

في نماذج النظام الأخرى ، أو عند إنشاء صفحة مدونة والمزيد من نماذج الإدارة "العادية" ، لا أرى هذا الخطأ. يبدو أنه يحدث عندما يكون ?nonce في عنوان url الخاص بالمسؤول (بالنسبة لي).

root@ahumaro-grav-php:/usr/share/nginx/html# bin/grav -V
Grav CLI Application version 1.1.12

إذا كان هناك بعض التشخيصات الأفضل الأخرى التي يمكنني تقديمها ، فيرجى إبلاغي بذلك.

tenken هل يمكنك PM لي المستخدم / المجلد الخاص بك على https://gitter.im/flaviocopes لإعادة إنشاء هذا بسرعة؟

تم التحقق من مشكلة

يبدو أن التبديل إلى صورة عامل الإرساء هذه باستخدام Apache يعمل بشكل جيد:
https://github.com/SocialEngine/docker-php-apache

يبدو أن صور عامل ميناء Nginx في البرية تكسر حفظ موضوع الهيدروجين.

أواجه نفس المشكلة مثل tenken باستخدام Nginx.

JordanMajd أنت تستخدم سمة عملاقة؟

مستخدمو Nginx: الرجاء تحديث nginx.conf:

    location / {
        try_files $uri $uri/ /index.php?_url=$uri&$query_string;
    }

حسنًا ، الإصدار الأصلي من المشاركة الأولى مختلف ، إعادة فتح المشكلة.

tenken يجب حل مشكلتك عن طريق

أواجه نفس المشكلة ، لكني أستخدم lighttpd. أفترض أنه يجب علي إضافة قاعدة lighttpd المكافئة كما هو الحال مع mahagr المنشور؟ ماذا يجب أن تكون هذه القاعدة؟

بالنسبة لي ، لن يؤدي تحديث التحول إلى اختفاءه ، لكن الانتقال إلى قسم إداري آخر والعودة إلى المنزل تسبب في اختفائه. Nginx.

تواجه نفس المشكلة مع Apache. تبدو القضية عشوائية إلى حد ما.

Shift-Refresh لا يساعد ، ولا مسح ملفات تعريف الارتباط. المشكلة ثابتة ، لا يمكنني حفظ أي إعدادات جسرية على الإطلاق :(

لديك نفس المشكلة بشكل عشوائي مع Apache و WAMP

هل تستخدمون جميعًا موضوعًا قائمًا على جسر الرافعة ؟؟؟

قضية خطيرة في حالتي

نحتاج إلى إيجاد خيط مشترك لأننا لا نستطيع تكرار هذه المشكلة.

بخلاف الظهور في واجهة المسؤول ، هل يتم تسجيل الخطأ بواسطة PHP؟ من أين انبثقت وماذا تسميها؟

بالنسبة لي ، يقوم المشرف بتسجيل الخروج بشكل عشوائي. أنا لا أستخدم موضوعًا قائمًا على جسر الرافعة. يبدو أن تعيين الخيار "آمن" ضمن "التكوين-> الجلسة" قد أصلحه (لا يزال قيد الاختبار) على الرغم من أنني لا أستخدم https ، لذلك يبدو الأمر غريبًا. تحديث: لم يؤد ذلك إلى حل المشكلة ، بل واجهتها مرة أخرى.

@ rhukster : في حالتي ، إنها مسألة عملاقة ، نعم.
لا يترك أي أخطاء في سجل الأخطاء الخاص بي :(

itsociaal هل أنت متأكد من تمرير معاملات الاستعلام إلى جاذبية؟

يمكنني تشغيله إذا قمت بالتعليق على الأسطر 74-76 في جهاز التوجيه العملاق .php:

        // Protect against CSRF Attacks.
        if (!in_array($method, ['GET', 'HEAD'], true) && !$this->checkSecurityToken()) {
           throw new \RuntimeException('Invalid security token; please reload the page and try again.', 403);
        }

لا يزال Gantry لا يتصرف بشكل مثالي بنسبة 100٪ بعد ذلك ، ولكنه قابل للاستخدام بنسبة 99٪ إذا قمت بالتعليق على هذه الأسطر الثلاثة :)
أعتقد أن هذه مشكلة عملاقة ثم مشكلة كبيرة ، على الرغم من أنني أشك في أن سطر تكوين vhost في تثبيت grav قد يساعد في حل هذه المشكلة.

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

انطلاقا من هذا ، تبدو مشكلتك متطابقة بالفعل مع المشكلات المذكورة أعلاه: لا يقوم خادمك بتمرير سلسلة الاستعلام إلى PHP. لا أعرف الإصلاح الخاص بـ lighttpd ، فربما تساعد بعض خدمات googling؟

شكرًا للنصيحة ، تمكنت من حل المشكلة لمضيفي lighttpd:
اضطررت لتغيير الخط:

url.rewrite-if-not-file = (
   "^(.*)$" => "index.php"
)

ل

url.rewrite-if-not-file = (
   "^(.*)$" => "index.php$1"
)

لذلك فإنه يمرر سلسلة الاستعلام بشكل صحيح. كما حلت بعض المشاكل الصغيرة الأخرى التي يبدو أن العملاقة تواجهها.
ربما يكون من الجيد تحديث تهيئة lighttpd الموصى بها بهذا التغيير؟

تضمين التغريدة ^

itsociaal هل يمكنك اختبار هذا العلاقات العامة؟ https://github.com/getgrav/grav/pull/1393

flaviocopes ، هذا هو بالفعل التغيير الدقيق الذي أجريته على التكوين الخاص بي ، باستثناء أنني لم يتم تثبيت grav في مجلد ، لذلك قمت بإزالة مسار '/ grav_path /' منه. يبدو أنه يعمل بشكل جيد الآن ، لم أواجه أي مشكلات غريبة حتى الآن :)

ما زلت بحاجة إلى التعليق على الأسطر 74-76 في جهاز التوجيه العملاقة.php للحصول على عملاقة للعب بشكل جيد ، لكنني أفترض أن هذه مشكلة عملاقة بحتة.

Uhm .. إذا كنت لا تزال بحاجة إلى هذا التغيير في العملاقة ، فلن يتم إصلاحه إذن. يجب أن يؤدي تغيير تكوين خادم الويب إلى حل المشكلة.

أنت على صواب 100٪. لقد عادت بالفعل التغييرات في router.php.

لقد أجريت تثبيتًا نظيفًا في الموقع الافتراضي (/ grav_path /) ، ويبدو أنه يمنعني بطريقة ما من الانتقال إلى / admin الآن. أتلقى خطأ 404 غير موجود. تعمل الواجهة الأمامية بشكل جيد مع التغيير.

إذا قمت بتغيير التكوين بحيث يتم تثبيت grav في الجذر (بدون / grav_path / في عنوان url) ، فإنه يعمل بشكل جيد مع التغيير.

أتلقى خطأ 404 غير موجود.

هذا ما حصلت عليه أيضا.
grav 1.2 على lighttpd 1.1.45 php 7.1.2 ، تم تثبيت grav في مجلد فرعي.
لذا فإن الإصلاح $1 غير مناسب تمامًا بعد.

يبدو أن المشكلة هي جهاز التوجيه في حالة خطيرة ، وسوف يتم الخلط إذا كان المسار يتضمن عنوان url كاملًا بما في ذلك سلسلة الاستعلام ، وسيحاول تحميل عنوان url / المسار الخاطئ.
أعتقد أنني تمكنت من إصلاحه في بيئة التطوير المحلية الخاصة بي ، لقد غيرت الخط في vhost.conf بإضافة "/" إليه ، لذلك أصبح نصه الآن:

"^/grav_path/(.*)$" => "/grav_path/index.php/$1"

يبدو أن هذا يعمل حتى الآن بالنسبة لي على كل من تثبيتات grav ، 1 في الجذر و 1 في مجلد فرعي.
سأقوم ببعض الاختبارات الإضافية ، ربما يستطيع Piraty أيضًا اختبار هذا التغيير لمعرفة ما إذا كان يحل المشكلة بالنسبة له أيضًا؟

رأيت هذا الخطأ مرتين في أول تسجيل دخول إلى لوحة المسؤول. تسجيل الدخول الثاني يعمل بشكل جيد.

Grav 1.2.2
المشرف 1.3.3

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

ghost أين يمكنني العثور على vhost.conf على استضافة Apache المشتركة دون الوصول إلى ssh؟ يبدو أنه لا يوجد مثل هذا الملف.

أستخدم خدمة المحلي الخاص بي من الإنترنت ، ولكن لا يمكنني تسجيل الدخول إلى المسؤول من عنوان url مثل http://a70261927.ngrok.io/admin بسبب خطأ invalid security token كل مرة.
كيف تصلح؟

أنا أستخدم traefik كخادم وكيل عكسي. عند توصيله بـ "الواجهة الخلفية" الخاصة بي ، أحصل على invalid security token عند محاولة تسجيل الدخول إلى حسابي https://example.com/admin .
لقد بحثت كثيرًا على كلا الجانبين: traefik و grav.

أخيرًا وجدت الخطأ: في تكوين traefik الخاص بي ، أحتاج إلى تكوين passHostHeader إلى true في تكوين الواجهة الأمامية.
إذا كان لدى أي شخص أسئلة بخصوص هذا ، فلا تتردد في مراسلتي على @ me.

drewisdorner شكرًا على النصيحة ، يعمل بشكل رائع مع Traefik.