كيفية ضبط مزود العضوية؟

Question

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

حسنًا ، أولاً ، للتوضيح: أعرف ما هي العضوية والدور ومزود الملف الشخصي ، وكيفية تنفيذ بلدي ، وكيفية تكوينها ، ومعظم الأشياء عنها.
يعد تنفيذ دور الموفر ومزود الملف الشخصي واضحًا جدًا ، لأنه يتطلب فقط CRUD بسيطًا معظم الوقت. (خط واحد من LINQ يكفي لنحو نصف أساليب Roleprovider.)

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

أنا أستعمل هذا تنفيذ العينة للإشارة ، ولكنه يحتوي أيضًا على العديد من التناقضات.

• على سبيل المثال ، يستخدم طريقة ValidateUser الخاصة بها للتحقق من بيانات الاعتماد في طريقة تغيير WASTERSPASSWORD. لكن VALAIDESUSER يقوم أيضًا بتحديث LastLogindate للمستخدم إلى التاريخ الحالي. لذا ، هل يتوقع الإطار أن أقوم بتعيينه في مزودتي الخاصة أيضًا ، أم أنه مجرد خطأ في العينة؟
• والآخر هو: طريقة ChangePassword ترمي استثناء في كل مرة عند التحقق من صحة كلمة المرور الجديدة ، ولكن CreateUser لا يرمي استثناءً ، فهو ببساطة يعيد خطأ.

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

• (تحرير) لقد نسيت تقريبا: طريقة CreateUser في العينة تدرج المعرف من معلمة الطريقة. أعتقد في الواقع أن هذه ممارسة سيئة ، لأنني أستخدم inters مع ecement Auto incement كمعرفات ، لذلك فإن إدخالها من معلمة طريقة ما ليس خيارًا. هل يجب أن أتجاهل المعلمة ، أو أتطلب أن تكون قيمتها فارغة ورمي استثناء إذا لم يكن كذلك؟

الكل في الكل ، هل لدى ASP.NET أي افتراضات حول سلوك العضوية provider؟
هل هناك أي وثائق تصف متى يجب أن ألقي استثناء أو مجرد إعادة فارغ؟

حاولت أيضًا العثور على مجموعة من اختبارات الوحدات العامة التي من شأنها أن توفر بعض التوجيهات حول السلوك المتوقع ، ولكن لا حظ ، وجدت الكثير من المقالات حول "اختبار الوحدة جيد" ، و "كيفية اختبار وحدة Ambultshipprovider" ، ولكن ليس واحد حيث سيكون هناك أي اختبارات فعلية.

شكرا مقدما للجميع!

Answer 1

يمكنك استشارة MSDN للحصول على التوجيه. على سبيل المثال، RoleProvider.RemoveUsersFromRoles يوفر التوجيه التالي:

يتم استدعاء remostUsersfromroles بواسطة removeUserfromrole و removeUsersfromrole و removeUserFromroles و removeUsersfromroles من فئة الأدوار لإزالة المستخدمين المحددة من الأدوار المحددة في مصدر البيانات. يتم تعديل أدوار ApplicationName التي تم تكوينها فقط.

إذا لم يتم العثور على أي من أسماء الأدوار المحددة لـ ApplicationName التي تم تكوينها ، فإننا نوصي بمزودك برمي providerexception.

إذا لم يرتبط أي من أسماء المستخدمين المحددة بأي من أسماء الأدوار المحددة لـ ApplicationName التي تم تكوينها ، فإننا نوصي بمزودك برمي providerexception.

إذا كان أي من أسماء المستخدمين المحددة فارغة أو عبارة

إذا كان أي من أسماء الأدوار المحددة خالية أو عبارة

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

و RoleProvider.GetRolesForUser يقول:

يتم استدعاء GetRolesForuser بواسطة طريقة GetRolesForuser لفئة الأدوار لاسترداد أسماء الأدوار التي يرتبط بها المستخدم المحدد من مصدر البيانات. يتم استرداد فقط الأدوار الخاصة بـ ApplicationName التي تم تكوينها.

في حالة عدم وجود أدوار للمستخدم المحدد لـ ApplicationName التي تم تكوينها ، فإننا نوصي بمزودك بإرجاع مجموعة سلسلة بدون عناصر.

إذا كان اسم المستخدم المحدد فارغًا أو عبارة

ولكن ، في الممارسة العملية ، هناك بعض الطرق والسلوكيات في كل مزود مطلوب ومتوقع. الباقي هو دعم للميزات التي ترغب في تنفيذها.

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

إذا كنت تستخدم العاكس وفحص SQLMembershipProvider ، فستلاحظ بعض الاختلافات البارزة ...

على سبيل المثال:

• تحديثات ValiatedUser تحديثات تسجيل الدخول لأنه ، حسنًا ، يقوم المستخدم بتسجيل الدخول ويقوم بذلك عن طريق الاتصال. checkpassword مع True for UpdatelastLogintime. تغيير كلمة المرور تستدعي نفس الطريقة ولكن يوفر كاذبة.

• تقبل طريقة CreateUser مزودًا لأن SPOC ستقبل أيضًا معلمة userId. هذا هو السماح للترفيه والتوليف بين الجداول العضوية والجداول المستخدمين. كمستهلك لواجهة برمجة التطبيقات (API) ، فلن تستخدم هذه الوظيفة عادة ولكن مكدس المزود يعمل داخليًا.

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

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

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

كملاحظة أخيرة ، أقترح عليك تجد و تحميل عينات مجموعة أدوات ASP.NET. يوفر لك رمز المصدر العام للمكدس الكامل SQL وسيعطيك بعض البصيرة حول كيفية تنفيذ مقدمي الخدمات "الحقيقيين".

بعد ذلك:

في هذه اللحظة بالذات ، أقوم بتنفيذ مكدس مزود SQLite كامل المتوافق بنسبة 100 ٪ مع مكدس SQL الافتراضي. يتحقق جناح الاختبار من التكافؤ السلوكي بين مكدتي و ASP.NET. إذا ضربت مدونتي عبر ملف التعريف الخاص بي واتصلت بي ، فسوف أخبرك عند اكتمال الاختبارات ويمكنك استخدامها كمعيار لما هو متوقع بالضبط من المكدس الافتراضي.