أفضل طريقة للسماح بملفات تعريف الارتباط لجلسة النطاق الفرعي باستخدام Tomcat

Question

افتراضيًا، سيقوم Tomcat بإنشاء ملف تعريف ارتباط للجلسة للمجال الحالي.

إذا كنت على www.example.com، فسيتم إنشاء ملف تعريف الارتباط الخاص بك لـ www.example.com (سيعمل فقط على www.example.com).بينما على سبيل المثال example.com سيتم إنشاؤه لـ .example.com (السلوك المرغوب، سيعمل على أي نطاق فرعي من example.com بالإضافة إلى example.com نفسه).

لقد رأيت بعض صمامات Tomcat التي يبدو أنها تعترض إنشاء ملفات تعريف الارتباط للجلسة وتنشئ ملف تعريف ارتباط بديل بالنطاق .example.com الصحيح، ولكن يبدو أن أيًا منها لا يعمل بشكل لا تشوبه شائبة ويبدو أنها جميعًا تترك ملف تعريف الارتباط الحالي وتترك فقط إنشاء واحدة جديدة.وهذا يعني أنه يتم إرسال ملفي تعريف ارتباط JSESSIONID مع كل طلب.

كنت أتساءل عما إذا كان أي شخص لديه حل نهائي لهذه المشكلة.

Answer 1

يبدو أن هذا مدعوم من خلال إعداد التكوين في الإصدار 6.0.27 وما بعده:

يتم التكوين عن طريق تحرير meta-inf/context.xml

u003CContextn sessionCookiePath="/something"n sessionCookieDomain=".domain.tld" />

https://issues.Apache.org/bugzilla/show_bug.cgi?id=48379

Answer 2

لقد مررت بكل هذا للتو بحثًا عن حل بسيط.بدأت أنظر إلى الأمر من منظور القط أولاً.

لا يمنح Tomcat إمكانية الوصول المباشر إلى تكوين ملف تعريف ارتباط المجال للجلسة، وبالتأكيد لم أرغب في تصحيح Tomcat المخصص لإصلاح هذه المشكلة كما هو موضح في بعض المنشورات الأخرى.

يبدو أيضًا أن الصمامات الموجودة في Tomcat تمثل حلاً للمشكلة نظرًا للقيود المفروضة على الوصول إلى الرؤوس وملفات تعريف الارتباط المضمنة في مواصفات Servlet.كما أنها تفشل تمامًا إذا تم تنفيذ استجابة http قبل أن يتم تمريرها إلى الصمام الخاص بك.

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

لقد قمت أولاً بتجربة توجيه mod_proxy ProxyPassReverseCookieDomain، لكنه لا يعمل مع ملفات تعريف الارتباط JSESSIONID لأن Tomcat لا يقوم بتعيين سمة المجال ولا يمكن لـ ProxyPassReverseCookieDomain العمل دون أن يكون نوع ما من المجال جزءًا من ملف تعريف الارتباط.

لقد صادفت أيضًا اختراقًا باستخدام ProxyPassReverseCookiePath حيث كانوا يعيدون كتابة المسار لإضافة سمة مجال إلى ملف تعريف الارتباط، ولكن بدا ذلك أمرًا فوضويًا لموقع الإنتاج.

لقد تمكنت أخيرًا من العمل من خلال إعادة كتابة رؤوس الاستجابة باستخدام الوحدة النمطية mod_headers في Apache كما ذكر Dave أعلاه.

لقد أضفت السطر التالي داخل تعريف المضيف الظاهري:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5"

يجب أن يكون ما ورد أعلاه سطرًا واحدًا في ملف التكوين.سيتم استبدال أي سمة مجال لملفات تعريف الارتباط JSESSIONID بـ ".example.com".إذا كان ملف تعريف الارتباط JSESSIONID لا يحتوي على سمة مجال، فسيضيف النمط سمة بقيمة ".example.com".كمكافأة، لا يعاني هذا الحل من مشكلة ملفات تعريف الارتباط JSESSION المزدوجة للصمامات.

يجب أن يعمل النمط مع ملفات تعريف الارتباط المتعددة في رأس Set-Cookie دون التأثير على ملفات تعريف الارتباط الأخرى في الرأس.ويجب أيضًا أن يكون قابلاً للتعديل للعمل مع ملفات تعريف الارتباط الأخرى عن طريق تغيير JSESSIONID في الجزء الأول من النموذج إلى اسم ملف تعريف الارتباط الذي تريده.

أنا لست مستخدمًا محترفًا، لذلك أنا متأكد من أن هناك بعض التحسينات التي يمكن إجراؤها على النمط، ولكن يبدو أنها تعمل لصالحنا حتى الآن.

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

Answer 3

لقد واجهت هذا في $DAYJOB.في حالتي كنت أرغب في تنفيذ تسجيل دخول SSL ثم إعادة التوجيه إلى صفحة غير SSL.المشكلة الأساسية في Tomcat هي الطريقة (من الذاكرة) SessionManager.configureSessionCookie التي تقوم بترميز جميع المتغيرات التي ترغب في الوصول إليها.

توصلت إلى بعض الأفكار، بما في ذلك الاختراق الفظيع بشكل خاص باستخدام mod_headers في Apache لإعادة كتابة ملف تعريف الارتباط بناءً على استبدال regex.

تتمثل الطريقة النهائية لحل هذه المشكلة في إرسال تصحيح إلى مطوري Tomcat الذي يضيف معلمات قابلة للتكوين إلى فئة SessionManager.

Answer 4

نظرًا لأن الجلسة (ومعرفها) تعتبر ذات قيمة فقط للتطبيق المُصدر، فقد تفضل البحث عن إعداد ملف تعريف ارتباط إضافي.ألقِ نظرة على Tomcats SingleSignOnValve، حيث يوفر ملف تعريف الارتباط الإضافي JSESSIONIDSSO (لاحظ ...SSO) لمسار الخادم "/" بدلاً من "/applicationName" (كما يتم تعيين ملفات تعريف الارتباط JSESSIONID عادةً).

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

سبب آخر لعدم تمكنك من استخدام ملف تعريف الارتباط لجلسة Tomcats لأغراضك الخاصة هو أن تطبيقات الويب المتعددة على نفس المضيف لها معرفات جلسة مختلفة.على سبيل المثالهناك ملفات تعريف ارتباط مختلفة لـ "/webapp1" و"/webapp2".إذا قمت بتوفير ملف تعريف الارتباط الخاص بـ "/webapp1" إلى "/webapp2"، فلن يتمكن هذا من العثور على الجلسة التي أشرت إليها، وسيبطل صلاحية ملف تعريف الارتباط الخاص بجلستك + ويقوم بتعيين ملف تعريف ارتباط جديد خاص به.سيتعين عليك إعادة كتابة كافة جلسات التعامل مع جلسة Tomcats لقبول قيم معرف الجلسة الخارجية (فكرة أمنية سيئة) أو لمشاركة حالة معينة بين التطبيقات.

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

Answer 5

لا يبدو أن تقنيات الصمامات مثالية بنسبة 100%.إذا كنت تجرؤ على تعديل Tomcat نفسه:

كاتالينا.جرة يحتوي على الفئة التالية: org.apache.catalina.connector.Request

الطلب له طريقة:

configureSessionCookie(Cookie cookie)

بالنسبة لبيئتنا، كان من الأفضل ترميزها فقط، ولكن يمكنك القيام بمنطق أكثر روعة:

cookie.setDomain(".xyz.com");

يبدو أن العمل على أكمل وجه.سيكون من الرائع أن يكون هذا قابلاً للتكوين في Tomcat.