لا يمكن تعيين FormauthenicationTicket.userdata في وضع Cookieless

Question

أحاول تنفيذ قسم "كتابة معلومات إلى userData" هذه المقالة, ، لكنه لا يعمل بشكل صحيح عندما يكون ملف تعريف الارتباط جزءًا من URI.

رمز بلدي:

// Create the cookie that contains the forms authentication ticket
HttpCookie authCookie = FormsAuthentication.GetAuthCookie( userName, createPersistantCookie );

// Get the FormsAuthenticationTicket out of the encrypted cookie
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt( authCookie.Value );

// Create a new FormsAuthenticationTicket that includes our custom User Data
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket( ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, "foo");

// Update the authCookie's Value to use the encrypted version of newTicket
authCookie.Value = FormsAuthentication.Encrypt( newTicket );

// Manually add the authCookie to the Cookies collection
HttpContext.Current.Response.Cookies.Add( authCookie );

// Determine redirect URL and send user there
string redirUrl = FormsAuthentication.GetRedirectUrl( userName, createPersistantCookie );

HttpContext.Current.Response.Redirect( redirUrl, false );

عند استخدام Cookieless ، تقوم الصفحة بإعادة توجيه ولكن لا تحصل على URI الصحيحة مع معلومات ملفات تعريف الارتباط فيه ، بحيث تعود إلى صفحة تسجيل الدخول الخاصة بي حيث يتم إرجاع request. حلقة لا نهاية لها تستتبع.

كيف يمكنني إعادة توجيه إلى URI المناسب؟

Answer 1

لقد وجدت أن هذه مشكلة مثيرة للاهتمام ، لذلك شرعت في القيام ببعض الحفر والاختبار وقليل من التصحيح في مصدر إطار .NET.

في الأساس ، ما تحاول القيام به لن ينجح. سيتم تجاهل أي شيء تضعه في مجموعة الاستجابة. يمكنك التحقق من request.browser.cookies لمعرفة ما إذا كانت ملفات تعريف الارتباط مدعومة.

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

يمكن لنظام المصادقة تخزين بياناته الخاصة في URI ، لكنه يفعل ذلك عن طريق معالجة URI نفسها مباشرة. للأسف ، لا يبدو أن Microsoft قد كشفت عن هذه القدرات للرمز خارج وحدة المصادقة.

في الأساس ، إذا كنت تستخدم أساليب مثل FormsAuthentication.getauthcookie () و Formauthentication. تذكرة المصادقة لهذه الطرق ... لذلك أنت عالق مع تذكرة Auth الافتراضية. في هذه الحالات ، أنت وحدك لتخزين أي بيانات مخصصة.

على أي حال...

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

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

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

Answer 2

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

قبل أن أفعل الرمز المذكور أعلاه:

if( !HttpContext.Current.Request.Browser.Cookies || !FormsAuthentication.CookiesSupported )
{
    FormsAuthentication.RedirectFromLoginPage( userName, false);
    return;
}