Sessions: ملف تعريف الارتباط الآمن: القيمة غير صالحة

تم إنشاؤها على ١٣ أكتوبر ٢٠١٣ · 9تعليقات · مصدر: gorilla/sessions

مرحبا،
تلقيت هذا الخطأ عند محاولة الاتصال بـ store.Get () بناءً على طلب من websocket.Conn.Request ()

session, err := store.Get(conn.Request(), "my_session")

نشأ الخطأ من وظيفة checkMac الخاصة بـ gorilla / securecookie.

مصدر

danvonk

التعليق الأكثر فائدة

لا يجب عليك تضمين المفاتيح / بيانات الاعتماد في كود المصدر الخاص بك. بدلاً من ذلك ، يجب عليك تمريرها عبر البيئة - على سبيل المثال os.Getenv("APPNAME_SESSION_KEY") . قد يتم تمهيد هذه البيئة بواسطة نظام النشر الخاص بك - في حالة k8s ، باستخدام وظيفة الأسرار: https://kubernetes.io/docs/concepts/configuration/secret/#using -secrets-as-environment-variables

elithrar في ٢٩ مايو ٢٠١٨

👍6

ال 9 كومينتر

ظمىمئءنؤى؟ :)

FraBle في ١٤ نوفمبر ٢٠١٣

أنا أرى هذا أيضًا وأود أن أعرف كيفية مسحه / حله.

dominichamon في ١٨ يونيو ٢٠١٥

هل سلوك الخطأ متسق؟ أم أنها تؤثر فقط على بعض الطلبات؟

يوم الخميس ، 18 يونيو 2015 الساعة 2:04 مساءً دومينيك هامون [email protected]
كتب:

أنا أرى هذا أيضًا وأود أن أعرف كيفية مسحه / حله.
-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/16#issuecomment -113047123.

elithrar في ١٨ يونيو ٢٠١٥

تمكنت من التخفيف من ذلك من خلال إعادة صفحة صالحة عندما أصبت بالخطأ (بدلاً من 500) ثم حذف ملف تعريف الارتباط يدويًا من المتصفح. أعتقد أن السبب في ذلك هو تحديث مفاتيح المصادقة / التشفير مع وجود ملف تعريف ارتباط على جانب المتصفح من جلسة حالية.

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

dominichamon في ١٨ يونيو ٢٠١٥

👍4

إذا كنت تريد تجنب ذلك ، فأنت بحاجة إلى طريقة لتطبيقك لترحيل المفاتيح.

kisielk في ١٨ يونيو ٢٠١٥

واجهت هذه القضية أيضا. انتهى بي الأمر بتجاهل الخطأ فقط ، لأن مستندات الغوريلا / الجلسات تقول إن جلسة جديدة ما زالت ترجع. لا يزال بإمكانك الاتصال بـ session.Save() ، وبعد ذلك سيحصل المتصفح الطالب على ملف تعريف ارتباط جلسة جديد وصالح.

nucleartide في ٢٨ سبتمبر ٢٠١٥

👍6

كنت أواجه نفس المشكلة وكان من الصعب تحديدها في البداية ، المشكلة هي أنني واجهت
var store = sessions.NewCookieStore(securecookie.GenerateRandomKey(10))
لذلك في كل مرة أقوم فيها بإعادة تشغيل الخادم ، يتم إنشاء مفتاح جديد للمخزن ، وإذا قمت مسبقًا بحفظ ملف تعريف الارتباط في متصفح الويب ، فقد يتسبب ذلك في حدوث خطأ عند محاولة فك تشفير ملف تعريف الارتباط لأنه يستخدم المفتاح الجديد و ليس المفتاح عند إنشاء ملف تعريف الارتباط في البداية.
قد يكون من الصعب تحديد هذه المشكلة حتى الأسوأ عند النشر في kubernetes ، لأنه في بعض الأحيان تحتاج العقدة (الجهاز) إلى إعادة التشغيل وستقوم هذه العقدة بإنشاء مفتاحها الخاص وقد يتسبب ذلك في حدوث تعارض مع العقد الأخرى. أوصي بعدم إنشاء مفتاح عشوائي ، وبدلاً من ذلك ، أدخل مفتاحًا يدويًا حتى لا تواجه هذه المشكلة ، مثل:
var store = sessions.NewCookieStore([]byte("asdaskdhasdhgsajdgasdsadksakdhasidoajsdousahdopj"))