Sessions: اذهب 1.7: http.Request.Context يقطع الغوريلا / استخدام السياق

تم إنشاؤها على ٤ يونيو ٢٠١٦ · 22تعليقات · مصدر: gorilla/sessions

ينشئ http.Request.Context() في Go 1.7 نسخة ضحلة من الطلب الأصلي الذي يتطلب من المتصل حفظه في أعلى الصفحة. هذه النسخة لها عنوان مختلف وبالتالي لها مفتاح خريطة مختلف في خريطة السياق المقدمة من قبل الغوريلا / السياق.

لإصلاح ذلك في الغوريلا / الجلسات ، نحتاج إلى إجراء تغيير جذري لمستخدمي Go 1.7+:

[] استخدم علامات الإنشاء لتوفير عمليتي تنفيذ للسياق وفقًا لـ gorilla / csrf: https://github.com/gorilla/csrf/blob/master/context_legacy.go
[] الاستخدام الوحيد لـ context.Set هو في حدود GetRegistry - سيحتاج هذا الآن إلى إرجاع (*Registry, *http.Request) .

- func GetRegistry(r *http.Request) *Registry {
+ func GetRegistry(r *http.Request) (*Registry, *http.Request)

[] هناك قدر معقول من الشفرة في البرية يمكن أن يؤدي إلى كسرها: https://github.com/search؟q=٪22sessions.GetRegistry٪22+language٪3Ago&type=Code&utf8=٪E2٪9C٪93 أكبر عدد ممكن المستخدمون يتصلون بـ sessions.GetRegistry(r).Get(store, name) . سيحتاجون إلى تغيير الكود الخاص بهم:

- sessions.GetRegistry(r).Get(s, name)
+ var reg *sessions.Registry
+ reg, r = sessions.GetRegistry(r)
+ sess, err := reg.Get(store, name)

يجب أن يكون عن ذلك. هذا أمر لا مفر منه لسوء الحظ ، ولكنه (لحسن الحظ) تغيير كسر وقت التجميع الذي يمكننا توثيقه بوضوح.

المرجع: https://github.com/gorilla/mux/issues/168

breaking change enhancement

مصدر

elithrar

👍15

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

ك ، حسنًا ، سأشرح ما يحيرني (كما قد يبدو غبيًا) ، لأنه قد يلقي بعض الوضوح على ما يختبره الآخرون. :ابتسامة:

عندما أقرأ (مستخدم مبتدئ) من خلال مستندات الجلسة ، يبدو الأمر واضحًا بشكل معقول حتى هذا الجزء:

Important Note: If you aren't using gorilla/mux, you need to wrap your handlers with
context.ClearHandler or else you will leak memory! An easy way to do this is to wrap
the top-level mux when calling http.ListenAndServe:

    http.ListenAndServe(":8080", context.ClearHandler(http.DefaultServeMux))

The ClearHandler function is provided by the gorilla/context package.

مع التطبيق الذي أقوم بتطويره ، فإنه يستخدم Go 1.8 ولا يستخدم gorilla / mux. لذا ، يبدو هذا التحذير وكأنه شيء يتعين علينا القيام به. من الواضح أن تسريب الذاكرة أمر سيء. هكذا:

تمت إضافة "سياق" فوري لوارداتنا
- لم يعمل. بعد إعادة قراءة الفقرة أعلاه تذكر حزمة gorilla/context . لذلك ، يجب أن يكون هذا هو الشخص المناسب للاستخدام.
انظر إلى صفحة الغوريلا / السياق. هذا الشخص لديه هذا التحذير بدلاً من ذلك:

Note: gorilla/context, having been born well before context.Context existed, does not
play well with the shallow copying of the request that http.Request.WithContext
(added to net/http Go 1.7 onwards) performs. You should either use just gorilla/context,
or moving forward, the new http.Request.Context().

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

حان وقت السؤال.

لقد أجبت بشكل مفيد:

If you are using Go 1.8 only and not importing gorilla/context (which includes
packages you are using), gorilla/mux defaults to the Go 1.7 http.Request.Context
implementation.

... لكن هذا لا يوضح الأشياء حقًا (بالنسبة لي). في حالتنا (مبتدئ) ، نحن لا نستخدم الغوريلا / مسك الغزال. نريد استخدام الغوريلا / الجلسات. لذا ، لا تتذمر كيف يلعب التخلف عن السداد في الغوريلا / مسك الغزال هناك.

على أي حال ، أعتقد أن ما أعنيه هو أنه يجب أن يكون هناك بيان واضح حول هذا الأمر. لا يبدو أن الإصدار الحالي يعالج الأشياء للمستخدمين الجدد (99.9 ٪ ممن سيستخدمون Go 1.7+) الذين لا يستخدمون أي حزم gorilla .

آمل أن لا أتعفن على الأشياء. :ابتسامة:

justinclift في ٢ أغسطس ٢٠١٧

👍5

ال 22 كومينتر

FWIW ، أستخدم حاليًا فرع shawnps أثناء انتظار هذا الدمج

ironcladlou في ١٨ أكتوبر ٢٠١٦

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

الرسم البياني أدناه هو المساحة قيد الاستخدام بعد إجراء اختبار قياس مدته 30 ثانية مقابل أحد المسارات / المعالجات في تطبيقنا الذي يخزن متغيرات الجلسة المختلفة في ملف تعريف ارتباط.

session-leak

jbrook في ٢٢ نوفمبر ٢٠١٦

cc jawnsy

ironcladlou في ٢٨ نوفمبر ٢٠١٦

شكرًا للتلميح ، الحل البديل هو حفظ الجلسة في request.context() يدويًا مع الاستمرار في تنظيف سياق gorialla في نهاية الطلب.

Niondir في ١٧ يوليو ٢٠١٧

أنا في حيرة من أمري من نتائج أعلاه ، وما إذا كان من الآمن استخدام هذه الحزمة مع Go 1.8.

إذا اتبع المرء نصيحة تغليف http.Handler بـ context.ClearHandler ، فهل نحن في مأمن من تراكم هذه المثيلات sessions.Registry في الذاكرة؟

seh في ٢١ يوليو ٢٠١٧

يستخدم context.ClearHandler الطلب لتنظيف البيانات ذات الصلة وقد لا يعمل بالفعل في بعض الحالات ويسرب بعض البيانات (يعتمد على أي نسخة طلب قد يتم إنشاؤها). ولكن هناك طريقة في حزمة السياق يمكن أن تساعد:

// Purge removes request data stored for longer than maxAge, in seconds.
// It returns the amount of requests removed.
//
// If maxAge <= 0, all request data is removed.
//
// This is only used for sanity check: in case context cleaning was not
// properly set some request data can be kept forever, consuming an increasing
// amount of memory. In case this is detected, Purge() must be called
// periodically until the problem is fixed.
func Purge(maxAge int) int {

ما عليك سوى إنشاء contextPurgeMiddleware يستدعي context.Purge(-1) بعد كل طلب. بالإضافة إلى ذلك ، يجب عليك التأكد من أنك لا تعتمد على أي gorilla.context لأن هذه البرامج الوسيطة ستمسح سياقات جميع الطلبات. يجب عليك فقط استخدام سياق go من.

Niondir في ٢١ يوليو ٢٠١٧

من خلال قراءتي لـ context.Purge ، خاصةً عند استدعائي باستخدام وسيطة غير إيجابية ، فإنه يحذف http.Request s التي قمنا بتخزين جلسة لها. هذا يعني أن sessions.(* CookieStore).Get ينشئ session.Registry s ، ولكن في كل مرة ننتهي من طلب معين ، نقوم بإزالة _ جميع_ هذه السجلات ، والتي قد يكون بعضها قيد الاستخدام في الطلبات التي ما زلنا نعالجها بشكل متزامن . ثم نقوم بإنشاء مخابئ بشكل فعال نتخلص منها دون تمييز ، ربما قبل أن نتمكن من الاستفادة منها.

ألن تكون النصيحة الأفضل هي تجنب كل استخدامات sessions.GetRegistry ؟ اتضح أننا لا نستطيع ، إذا كنت تنوي الاتصال بـ sessions.Save . يتعين علينا تجنب هذه الوظيفة واستخدام ، على سبيل المثال ، sessions.(*CookieStore).Save مباشرة ، وهو أقل عملية بكثير.

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

يبدو الاقتراح الأصلي هنا من elithrar معقولًا ، على الرغم من أنني لست متأكدًا حتى الآن من كيف يمكن للمتصلين بـ GetRegistry الذي أهتم به - sessions.(* CookieStore).Get و sessions.Save - للتغيير أيضا.

seh في ٢٢ يوليو ٢٠١٧

من المحتمل أن يتم تقليص حجم السجل إذا انتقلنا إلى السياق
داخليا. سيكون بمثابة "طبقة رقيقة" عند الوصول إليها
session.calues أو call session.Save (وهو في الغالب ما هو عليه الآن).

السياقات المرتبطة بـ http.Request عبر Request.WithContext سوف
يتم تعديله تلقائيًا وبالتالي لا نحتاج إلى آلية "تطهير".

يوم الجمعة ، 21 تموز (يوليو) 2017 ، الساعة 7:12 مساءً ، Steven E. Harris [email protected]
كتب:

من خلال قراءتي للسياق. الاندفاع ، خاصة عند استدعائها بغير إيجابي
جدال
https://sourcegraph.com/github.com/gorilla/context/-/blob/context.go#L119-123 ،
يقوم بحذف جميع البيانات المرتبطة بكل طلبات http
قمنا بتخزين جلسة. وهذا يعني أن الجلسات. (* CookieStore)
ينشئ جلسة. السجلات ، ولكن في كل مرة ننتهي من طلب معين ،
نقوم بإزالة كل هذه السجلات ، والتي قد يكون بعضها قيد الاستخدام في
الطلبات التي ما زلنا نعالجها بشكل متزامن. ثم نكون فعالين
إنشاء مخابئ نتخلص منها بشكل عشوائي ، ربما قبل أن نتمكن من ذلك
من أي وقت مضى الاستفادة منها.
ألن تكون النصيحة الصحيحة هي تجنب كل استخدام
الجلسات. اتضح أننا لا نستطيع ، إذا كنا نعتزم الاتصال
جلسات
https://sourcegraph.com/github.com/gorilla/sessions/-/blob/sessions.go#L189-190 .
يجب علينا تجنب هذه الوظيفة واستخدام الجلسات ، على سبيل المثال. (* CookieStore)
بشكل مباشر ، وهو أقل عملية بكثير.
ما هذه الفوضى. لدينا محاولة تحسين تبين أنها ملف
مشكلة أكبر ، مثل إخفاء الأشياء في المتغيرات العالمية في كثير من الأحيان ،
ونحن الآن نواجه مشكلة في إعادة صياغتها لتكون متخلفة
متوافق. ليس لدي أي تطبيق سابق يستخدم هذه الحزمة ، لذا فأنا أكثر
مهتم بكيفية كسرها لإصلاحها.
الاقتراح الأصلي هنا من elithrar https://github.com/elithrar
يبدو معقولًا ، على الرغم من أنني لست متأكدًا بعد من كيفية اتصال المتصلين بـ GetRegistry
التي أنا مهتم بها - الجلسات. (* CookieStore). احصل على الجلسات ، وحفظ - سوف
يجب أن تتغير أيضا.
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-317147378 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcCHZxevsfN5aDaTCBTLIlyEVR9Ehks5sQVqigaJpZM4IuFUJ
.

elithrar في ٢٢ يوليو ٢٠١٧

أعتقد أني أرى طريقة لتجنب كل استخدام للنوع Registry مع الحزمة كما هي ، لكن القيام بذلك يتطلب دراسة متأنية وعناية. أوافق على أن استخدام http.Request.WithContext هو الطريقة التي يجب اتباعها لتخزين هذه الأشياء مؤقتًا ، لكن هذا يجبر المتصلين على التعامل مع قيم http.Request المنسوخة.

الطريقة التي يعمل بها http.Request.WithContext هي تعديل تحديثي غريب. أود العثور على الأساس المنطقي للتصميم الذي يفرض أن يكون حقل "ctx" الخاص بـ http.Request غير قابل للتغيير. أفترض أنه عندما يستخدم أحدهم http.Request في سياق خادم - على عكس إعداد طلب كعميل - فمن المنطقي معاملة الطلب على أنه شيء ثابت.

تعرض هذه المقالة (أعتذر عن الارتباط بالمتوسط) مثالاً لمعالج HTTP "خارجي" يقوم بإعداد مساهمة في سياق الطلب ، وتمرير نتيجة http.Request.WithContext مباشرة إلى المعالج "الداخلي" المفوض التالي. هذا يبدو طبيعيا. تعتبر محاولة استخدام هذه الحزمة لها أمرًا محرجًا ، لأنه لا يوجد التفاف أو تفويض للمعالج في اللعب يؤسس نطاقًا متضمنًا ومضمونًا لتغيير السياق.

seh في ٢٢ يوليو ٢٠١٧

ملاحظة: إعادة بناء هذه المكتبة وكسر واجهة برمجة التطبيقات أسهل على ملف
المستوى التقني من العمل ضمن القيود الحالية.

ومع ذلك ، هناك قدر كبير من القصور الذاتي في المستخدمين الحاليين
لا تستخدم أدوات البيع - هذه الحزمة تتابعها + تجذب العديد من الأشخاص
جديدة على Go. كنت آمل أن تكون "dep" هي الإصدار 1 الآن حتى نتمكن من ذلك على الأقل
إرشاد المستخدمين إلى حل مثبت (بائع العلامة القديمة) ولكن للأسف.
يوم السبت 22 يوليو 2017 الساعة 6:53 صباحًا Steven E. Harris [email protected]
كتب:

أعتقد أنني أرى طريقة لتجنب كل استخدام لنوع التسجيل بامتداد
الحزمة كما هي ، ولكن القيام بذلك يتطلب دراسة متأنية والاجتهاد. أنا موافق
أن استخدام http.Request.WithContext هو السبيل للذهاب لتخزين هذه الملفات مؤقتًا
الأشياء ، ولكن هذا يجبر المتصلين على التعامل مع http.Request المنسوخ
القيم.
الطريقة التي يعمل بها http.Request.WithContext هي تعديل تحديثي غريب. أود أن
للعثور على الأساس المنطقي للتصميم الذي فرض "ctx" الخاص بـ http.Request
يكون المجال غير قابل للتغيير. أفترض أنه عندما يستخدم أحدهم http.Request في ملف
سياق الخادم - على عكس إعداد طلب كعميل - يقوم به
من المنطقي معاملة الطلب على أنه شيء ثابت.
هذا المقال
https://medium.com/@matryer/context-has-arrived-per-request-state-in-go-1-7-4d095be83 XX
(أعتذر عن الارتباط بالمتوسط) يظهر مثالاً على HTTP "خارجي"
معالج إعداد مساهمة في سياق الطلب ، وتمرير
نتيجة http.Request.WithContext مباشرة إلى المفوض التالي
معالج "داخلي". هذا يبدو طبيعيا. محاولة استخدام هذه الحزمة لها
محرجًا ، لأنه لا يوجد غلاف معالج أو تفويض في اللعب
يؤسس مدى احتواء ومضمون لتغيير السياق.
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-317185062 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcDCORtCLuB5h7xon9JTyZrie4ITlks5sQf7XgaJpZM4IuFUJ
.

elithrar في ٢٤ يوليو ٢٠١٧

خلال عطلة نهاية الأسبوع ، كتبت هذه المكتبة للمساعدة في استخدام _gorilla / Session_ دون لمس session.Registry . إنه يحتاج إلى وثائق وأمثلة ، لكنني آمل أن تتمكن من الحصول على الجوهر من الوثائق على مستوى الوظيفة الموجودة هناك.

seh في ٢٤ يوليو ٢٠١٧

حسنًا ، بصفتي مبرمجًا جديدًا في Golang يتطلع إلى استخدام الغوريلا / الجلسات لأول مرة ... هل يؤثر هذا على قاعدة الشفرة التي أعمل عليها؟ (باستخدام Go 1.8 ، وعدم استخدام أي حزمة سياق صريحة بالفعل)

يقول مستند README الحالي:

Important Note: If you aren't using gorilla/mux, you need to wrap your handlers
with context.ClearHandler ...

والذي تبين أنه يعني gorilla/context ( فقط ). : wink: بالنظر إلى العديد من القضايا هنا والعلاقات العامة المفتوحة حول مستندات الذاكرة ، يبدو أن هذا يتعارض مع حزمة Go 1.7+ context .

هممم ، هل يحتاج جزء المستند هذا إلى التحديث ليقول شيئًا أكثر مثل:

Important Note: If you are using gorilla/content, but aren't using gorilla/mux, you
need to wrap your handlers with context.ClearHandler ...

انها مربكة جدا أجهزة الصراف الآلي. :غمزة:

justinclift في ٢ أغسطس ٢٠١٧

إذا كنت تستخدم Go 1.8 فقط ولا تستورد gorilla / Context (أي
يتضمن الحزم التي تستخدمها) ، الإعدادات الافتراضية gorilla / mux هي Go 1.7
تنفيذ http.Request.Context.

يوم الأربعاء ، 2 أغسطس ، 2017 الساعة 7:42 صباحًا ، جوستين كليفت إخطارات @github.com
كتب:

حسنًا ، بصفتك مبرمجًا جديدًا من Golang يتطلع إلى استخدام الغوريلا / الجلسات
لأول مرة ... هل يؤثر هذا على قاعدة الشفرة التي أعمل عليها؟ (استخدام
اذهب 1.8 ، ولم تستخدم بالفعل أي حزمة سياق صريحة)
يقول مستند README الحالي:
ملاحظة مهمة: إذا كنت لا تستخدم الغوريلا / مسك الغزال ، فأنت بحاجة إلى لف معالجاتك
مع السياق ClearHandler ...
الذي تبين أنه يعني الغوريلا / السياق ( فقط ). 😉 النظر إلى مختلف
القضايا هنا والعلاقات العامة المفتوحة حول مستندات الذاكرة يبدو أن هذا يتعارض
مع حزمة السياق Go 1.7+.
هممم ، هل يحتاج جزء المستند هذا إلى التحديث ليقول شيئًا أكثر مثل:
ملاحظة مهمة: إذا كنت تستخدم الغوريلا / المحتوى ، ولكنك لا تستخدم الغوريلا / مس ، فأنت
تحتاج إلى التفاف معالجاتك بالسياق. ClearHandler ...
انها مربكة جدا أجهزة الصراف الآلي. 😉
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-319693852 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcLwCza_i7Hm2BWqOC4EmNJKpHqOTks5sUIrdgaJpZM4IuFUJ
.

elithrar في ٢ أغسطس ٢٠١٧

رائع. ما هي الطريقة الصحيحة لإيصال ذلك إلى مطوري Go الجدد ، حتى يعرفوا ما إذا كانوا سيحتاجون إلى تغيير / وماذا؟ :ابتسامة:

justinclift في ٢ أغسطس ٢٠١٧

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

(هذه الأشياء كثيفة أيضًا ، لذا يصعب على المطورين الجدد القيام بذلك
فهم - ليس خطأهم ، نحن نتعامل مع ديون التكنولوجيا)

يوم الأربعاء 2 أغسطس 2017 الساعة 8:45 صباحًا Justin Clift [email protected]
كتب:

رائع. ما هي الطريقة الصحيحة لإبلاغ مطوري Go الجدد بذلك
يعرفون ما إذا / ما الذي سيحتاجون إلى تغييره؟ 😄
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-319712987 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcHEAAbp0Q5-FGSbGzj3TgO7IJ42Qks5sUJmugaJpZM4IuFUJ
.

elithrar في ٢ أغسطس ٢٠١٧

ك ، حسنًا ، سأشرح ما يحيرني (كما قد يبدو غبيًا) ، لأنه قد يلقي بعض الوضوح على ما يختبره الآخرون. :ابتسامة:

عندما أقرأ (مستخدم مبتدئ) من خلال مستندات الجلسة ، يبدو الأمر واضحًا بشكل معقول حتى هذا الجزء:

Important Note: If you aren't using gorilla/mux, you need to wrap your handlers with
context.ClearHandler or else you will leak memory! An easy way to do this is to wrap
the top-level mux when calling http.ListenAndServe:

    http.ListenAndServe(":8080", context.ClearHandler(http.DefaultServeMux))

The ClearHandler function is provided by the gorilla/context package.

تمت إضافة "سياق" فوري لوارداتنا
- لم يعمل. بعد إعادة قراءة الفقرة أعلاه تذكر حزمة gorilla/context . لذلك ، يجب أن يكون هذا هو الشخص المناسب للاستخدام.
انظر إلى صفحة الغوريلا / السياق. هذا الشخص لديه هذا التحذير بدلاً من ذلك:

Note: gorilla/context, having been born well before context.Context existed, does not
play well with the shallow copying of the request that http.Request.WithContext
(added to net/http Go 1.7 onwards) performs. You should either use just gorilla/context,
or moving forward, the new http.Request.Context().

حان وقت السؤال.

لقد أجبت بشكل مفيد:

If you are using Go 1.8 only and not importing gorilla/context (which includes
packages you are using), gorilla/mux defaults to the Go 1.7 http.Request.Context
implementation.

آمل أن لا أتعفن على الأشياء. :ابتسامة:

justinclift في ٢ أغسطس ٢٠١٧

👍5

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

kemitche في ٢٢ يناير ٢٠١٨

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

elithrar في ٢٢ يناير ٢٠١٨

❤1

هل تم إغلاقه مؤخرًا بواسطة PR # 175؟

flibustenet في ٢ مارس ٢٠١٩

صيح.
يوم السبت ، 2 مارس 2019 الساعة 3:32 صباحًا كتب Wilk [email protected] :

هل تم إغلاقه مؤخرًا بواسطة PR # 175
https://github.com/gorilla/sessions/pull/175 ؟
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-468912351 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcNJckK9bhN3R0GYa1XbQ4wkGGgtGks5vSmFngaJpZM4IuFUJ
.

elithrar في ٢ مارس ٢٠١٩

حسنًا ، هل تخطط لإجراء إصدار بسيط بهذا التغيير أم لا تزال تقفز إلى الإصدار 2 من أجل هذا؟

flibustenet في ٤ مارس ٢٠١٩

سأقطع إصدارًا ثانويًا جديدًا لهذا قريبًا.

في يوم الإثنين 4 مارس 2019 الساعة 1:37 صباحًا كتب Wilk [email protected] :

حسنًا ، هل تخطط لإجراء تحرير بسيط بهذا التغيير أم لا تزال تقفز
إلى الإصدار 2 من أجل هذا؟
-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gorilla/sessions/issues/80#issuecomment-469183709 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABIcKKWgsG7MP9P1N8ZvaEtwlQuT_ebks5vTOlbgaJpZM4IuFUJ
.

elithrar في ٤ مارس ٢٠١٩

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات

القضايا ذات الصلة

متاجر الطرف الثالث لا تطبق الخيارات على برامج الترميز بشكل صحيح.

marksalpeter · 17تعليقات

إزالة جلسة عند استخدام FilesystemStore

luca-moser · 3تعليقات

حالة السباق في FilesystemStore

cless · 23تعليقات

أنشئ جلسة جديدة مدعومة من نظام الملفات إذا تعذر العثور على تطابق

gtaylor · 7تعليقات

كيف ستبدو الغوريلا / الجلسات v2؟

elithrar · 25تعليقات