سؤال RFC حول ملفات تعريف الارتباط والمسارات

Question

أحاول تعيين ملف تعريف ارتباط للجلسة مقصورة على مسار معين (دعنا نقول /foo) عندما يقوم المستخدم بتسجيل الدخول. المضاعفات هي أن صفحة تسجيل الدخول قيد التشغيل /, ، لكن الطلب يعيد التوجيه على الفور إلى /foo/something. شيء من هذا القبيل:

طلب:

POST / HTTP/1.1

username=foo&password=bar

إجابة:

HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo

ومع ذلك ، فإن البتات ذات الصلة من RFCs يمكن أن أجدها (RFC2109 و RFC2965) قل هذا:

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

• قيمة سمة المسار ليست بادئة للطلب.

...

يبدو أن عملية وضع ملفات تعريف الارتباط الموضحة أعلاه الشغل حسنًا ، ولكن بقدر ما أستطيع أن أقول إن RFCs تقول أنه لا ينبغي.

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

هل أخطأ في قراءة RFCs؟

شكرا لك مقدما!

Answer 1

لا تولي أي اهتمام لتلك RFCs. أنها تختلف عن الواقع بشكل سيء للغاية.

يوجد حاليًا IETF WG تقوم بتوثيق سلوك ملفات تعريف الارتباط الفعلي ؛ وثيقةهم ، على الرغم من مجرد مسودة ، هي مواد مصدر أفضل بكثير.

يرى: http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/

إذا لم تجد نصًا يعالج سؤالك في المسودة ، فأرضمه مع مجموعة العمل!

Answer 2

بناءً على سؤالك ، أعتقد أن فهمك لـ RFC صحيح. يبدو أنك تريد ضبط ملف تعريف الارتباط بعد إعادة التوجيه إلى '/foo/home'. أعتقد أن السؤال الحقيقي هو: "كيف تقول '/foo/home' تم مصادقة المستخدم بشكل صحيح '/'?"

إذا كان يجب عليك استخدام رأس الموقع (إعادة التوجيه) للوصول من '/' ل '/foo/home', ، يبدو أن الطريقة الوحيدة للقيام بذلك هي استخدام معلمة سلسلة الاستعلام في قيمة رأس الموقع.

ربما يكون سؤال التصميم الذي يجب مراعاته هو: لماذا يقوم المستخدمون المصادقة على عنوان URL خارج المسار الذي سيصلون إليه بشكل آمن؟ إذا كان المحتوى الآمن الوحيد تحت "/فو", ، فلماذا لا تنشر ل '/فو/تسجيل الدخول بدلاً من '/' للمصادقة؟