هل مؤشر ترابط HTTPSASTERESS آمن ، هل يتم تعيين العمليات الآمنة لخيط السمة؟

Question

أيضًا ، هل يجب أن يكون الكائن الذي يتم تعيينه آمنًا لضمان أن نعرف ما هي حالة الكائن المخزن في الجلسة المعروفة.

أيضًا ، كنت أقرأ على الويب يقترح البعض استخدامه:

synchronized(session) {
  session.setAttribute("abc", "abc");
}

هل هذا اقتراح صحيح؟

Answer 1

لا ، فهي ليست آمنة ، وفقًا لـ IBM - نظرية وممارسة Java: هل كل تطبيقات الويب مفيدة؟. تحتاج إلى مزامنة.

كيف أن httpsession ليس مؤلم من Java Ranch قد يكون مفيدًا أيضًا.

Answer 2

Servlet 2.5 Spec:

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

هذا آمن:

// guaranteed by the spec to be safe
request.getSession().setAttribute("foo", 1);

هذا هو ليس آمنة:

HttpSession session = request.getSession();
Integer n = (Integer) session.getAttribute("foo");
// not thread safe
// another thread might be have got stale value between get and set
session.setAttribute("foo", (n == null) ? 1 : n + 1);

هذا هو ليس مضمون أن تكون آمنًا:

// no guarantee that same instance will be returned,
// nor that session will lock on "this"
HttpSession session = request.getSession();
synchronized (session) {
  Integer n = (Integer) session.getAttribute("foo");
  session.setAttribute("foo", (n == null) ? 1 : n + 1);
}

لقد رأيت هذا النهج الأخير دعا (بما في ذلك في كتب J2EE) ، لكن ليس من الضمان العمل من خلال مواصفات Servlet. يمكنك استخدم معرف الجلسة لإنشاء mutex, ، ولكن يجب أن يكون هناك نهج أفضل.

Answer 3

لا. وبما أنك لا تريد نفس العميل (مع الجلسة) لتقديم الطلبات المتزامنة ، يجب عليك إجراء تسلسل هذه الطلبات مثل الملخص يفعل في الربيع MVC

Answer 4

في بعض النواحي ، يعتمد هذا على تصميم العميل الخاص بك.

هل تتاح لك الفرصة ، في تصميم الويب الخاص بك ، لعميل واحد للحصول على طلبات متعددة متزامنة باستخدام جلسة HTTP نفسها؟ يبدو من الصعب القيام بذلك إلا إذا قمت بربط جلسة HTTP واحدة بمآخذ متعددة. (AKA ، AJAX) أقل من القيام بذلك ، سيكون وصول HTTP الخاص بالعميل المعطى واحد بقدر ما يتعلق الأمر بالخادم ، مما يعني أن جلسة واحدة آمنة بشكل فعال.

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

Answer 5

إنهم ليسوا كذلك ، ولكن في معظم الأوقات ، سيقوم عملاؤك بالوصول إليهم فقط بخيط واحد.

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

كما يشير إدي ، فإن أحد المواقف التي قد تواجه فيها خيطين يصلان إلى نفس الجلسة ، وهما مكالمتان من Ajax يحاولان تعديل سمة الجلسة نفسها. وإلا فلن تواجه مشاكل.

Answer 6

الجلسة ليست آمنة لخيط الخيط ولا يتم ضمان أن تكون الأساليب المحددة آمنة. بشكل عام في حاوية servlet ، يجب أن تفترض أن تكون في بيئة متعددة الخيوط ولا توجد أدوات متوفرة آمنة.

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

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