كيفية فصل ملفات تعريف الارتباط الكبيرة في Asp.Net Identity إلى ملفات أصغر للسماح بالعديد من المطالبات؟

Question

أنا أعمل على نموذج أولي لترخيص قائم على المطالبات لتطبيق MVC الخاص بنا.نحن نستخدم هوية Asp.Net للمصادقة.

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

يحتوي تطبيقنا بالفعل على أكثر من 800 إجراء ويستمر في النمو.لقد قمت بإنشاء تطبيق اختباري صغير لمعرفة كيفية التعامل مع هذا العدد من المطالبات.ووقع في مشكلة: تقتصر ملفات تعريف الارتباط على 4092 بايت.

كما أن وجود عدد كبير من المطالبات يزيد من ملف تعريف ارتباط مصادقة الهوية.حوالي 600 مطالبة بأسماء/قيم قصيرة (5 أحرف لكل منها) تعطيني ملف تعريف ارتباط بحجم يزيد عن 4K والمستخدم الذي لديه هذا العدد من المطالبات لا يمكنه تسجيل الدخول - لا يمكن تعيين ملف تعريف الارتباط في المتصفح.

و600 مطالبة ليست حدًا أقصى لتطبيقنا.ربما سنحتاج إلى أكثر من ذلك.

هل هناك طريقة لفصل ملف تعريف الارتباط المصادقة إلى عدد قليل من ملفات تعريف الارتباط الأصغر؟

ملاحظة.إذا كنت فضوليًا، فإليك موقعي رمز المطالبات "الملف التعريفي" جنبا إلى جنب مع بقية المشروع.

ص.أعرف عن الآثار المترتبة على الأداء لملفات تعريف الارتباط الكبيرة.لا داعي للقلق بشأن ذلك الآن.

تحديث حاليًا لا يوجد حل خارج الصندوق لإجابتي.لكن يبدو أنني لست الوحيد الذي يعاني من هذه المشكلة. Microsoft.Owin يتعامل مع ملف تعريف الارتباط للمصادقة.والكود المصدري الحالي لـ Owin.Cookies موجود ChunkingCookieManager والذي تم تعيينه بشكل افتراضي في CookieAuthenticationMiddleware.

الأخبار السيئة هي أن هذا الرمز جديد جدًا (تم تسجيل الوصول إليه في 10 يوليو 2014، وكان عمره 20 يومًا فقط).إنه متاح من خلال الإصدار المسبق لـ nuget Microsoft.Owin.Security.Cookies.لست متأكدًا من رغبتي في استخدام RC2 في موقع الإنتاج.

هل هناك طريقة أخرى؟

Answer 1

لم أحل السؤال المباشر.ملف تعريف الارتباط كبير جدًا وسيظل كبيرًا مع وجود عدد كبير أو مطالبات كبيرة.لدى Owin v3.0 (حاليًا في RC2، وليس جاهزًا للإنتاج) طريقة لتقطيع ملفات تعريف الارتباط إلى ملفات أصغر.لكن ملفات تعريف الارتباط الكبيرة سيئة فقط.لذلك أحتفظ بالمطالبات من جانب الخادم فقط.

كان لدي مناقشة في منتدى الهوية ووجد هذا السؤال الذي يجيب على أسئلتي تماما.بناءً على السؤال، قمت بتنفيذ الحل الخاص بي ووضعت نموذجًا أوليًا لتطبيق MVC صغيرًا: https://github.com/trailmax/ClaimsAuthorisation.

جوهر الحل في روتين بدء التشغيل وهناك مرشح إم في سي يتحقق مما إذا كانت المطالبات المطلوبة متاحة للمستخدم.

Answer 2

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

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

انظر الأسئلة ذات الصلة أدناه.

تقييد الوصول إلى السجلات.هل الأذونات القائمة على المطالبة فكرة جيدة

مطالبات إذن لموارد محددة

Answer 3

يجب عليك استخدام الدور

[Authorize(Roles = "Admin, Role1")]
  public ActionResult Index(string id)
{....}
[Authorize(Roles = "Admin, Role2")]
  public ActionResult Index2(string id)
{....}
[Authorize(Roles = "Admin, Role1, Role3")]
  public ActionResult Index3(string id)
{....}