آلية مصادقة أمان النموذج المستندة إلى دور ASP.NET

المؤلف: ويلموف && هيث ستيوارت
الصفحة الرئيسية: http://www.amuhouse.com
البريد الإلكتروني: [email protected]
ملاحظة: لقد تعلمت استخدام ASP.NET منذ شهرين، وشاهدت مقالة بعنوان "الأمان المستند إلى الأدوار مع مصادقة النماذج" على موقع codeproject.com ووجدته مفيدًا للغاية. في ذلك الوقت أردت ترجمته إلى اللغة الصينية. ومع ذلك، فإن الترجمة المباشرة مملة حقًا. في اليومين الماضيين، أشرت إلى هذه المقالة التي كتبها هيث ستيوارت، وبناءً على فهمي الخاص، كتبتها باللغة الصينية وفقًا لأفكاري وتعبيراتي. مرفق تطبيق ويب تجريبي قمت بإعداده لهذه المقالة.
إذا كان هناك أي سوء فهم، يرجى الكتابة للإشارة إليه أو ترك تعليق.

ملاحظة: البريد العشوائي مزعج حقًا، يرجى إظهار احترامك.

المقالة الأصلية موجودة على http://www.codeproject.com/aspnet/formsroleauth.asp
المؤلف الأصلي هيث ستيوارت

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

مقدمة:

تعد مصادقة النموذج في ASP.NET ميزة قوية للغاية ولا تتطلب سوى كمية صغيرة من التعليمات البرمجية لتنفيذ نظام مصادقة أمان بسيط مستقل عن النظام الأساسي.
ومع ذلك، إذا كنت بحاجة إلى آلية مصادقة أكثر تعقيدًا وفعالية، فستحتاج إلى الاستفادة من مرونتها من خلال تقسيم العديد من المستخدمين إلى مجموعات مستخدمين. توفر مصادقة Windows المتكاملة آلية المصادقة هذه، ولكنها تستخدم NTLM، Windows NT LAN Manager، لذا فهي ليست مشتركة بين الأنظمة الأساسية. الآن يستخدم المزيد والمزيد من الأشخاص أنظمة Linux، وهناك المزيد والمزيد من مستخدمي متصفح Mozilla Forefox، وبالتأكيد لا يمكننا إبعاد هؤلاء الأشخاص، لذلك نبحث عن آلية مصادقة أخرى. هناك خياران: الأول هو تقسيم موقع الويب إلى مناطق متعددة وتوفير صفحات تسجيل دخول متعددة، مما يجبر المستخدمين على التسجيل وتسجيل الدخول واحدًا تلو الآخر، والآخر هو تجميع المستخدمين وتقييد حقوق الوصول لمجموعات مستخدمين محددة إلى صفحة معينة أو المنطقة. وهذا الأخير هو بالتأكيد الخيار الأفضل. يمكننا تحقيق هذه الوظيفة عن طريق تعيين الأدوار للمستخدمين الفرديين.

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

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

1. لإنشاء قاعدة بيانات،

يجب عليك أولاً اختيار نظام إدارة قاعدة البيانات DBMS الذي تريد استخدامه. تستخدم هذه المقالة SQL Server 2000.

في قاعدة بيانات مشاريع التطبيق الفعلية، يوجد عادةً جدول بيانات المستخدم المستخدمين، والذي قد يتضمن العلامة الفريدة للمستخدم: معرف المستخدم، واسم المستخدم: اسم المستخدم، وكلمة المرور: كلمة المرور، وعنوان البريد الإلكتروني للمستخدم: البريد الإلكتروني، ومدينة المستخدم: المدينة، وعدد تسجيلات دخول المستخدم LoginCount وما إلى ذلك. يمكنك تعيين أدوار للمستخدمين عن طريق إنشاء جدول بيانات UserInRoles (يتضمن بشكل عام حقلين، اسم المستخدم: اسم المستخدم، دور المستخدم: UserRoles).

من أجل التبسيط، أقوم فقط بإنشاء جدول بيانات المستخدمين، والذي يحتوي على 3 حقول، اسم المستخدم واسم المستخدم وكلمة المرور وكلمة المرور وأدوار المستخدم. قبل إنشاء جدول، تحتاج إلى تحديد قاعدة بيانات أو إنشاء قاعدة بيانات جديدة. لإنشاء قاعدة بيانات جديدة باسم WebSolution، لا يلزم سوى عبارة SQL بسيطة:

رمز البرنامج
إنشاء قاعدة بيانات WebSolution

لتحديد قاعدة بيانات تسمى msdb

في GO

رمز البرنامج
استخدم ام اس دي بي
يذهب

بعد ذلك، نقوم بإنشاء جدول بيانات المستخدمين المذكور للتو. ويكون البرنامج النصي SQL كما يلي:

رمز البرنامج

إنشاء مستخدمي TABLE
(
اسم المستخدم nvarchar(100) CONSTRAINT PK_UserName PRIMARY KEY،
كلمة المرور نفارتشار (150)،
أدوار المستخدم nvarchar(100)
)

يمكنه إنشاء بيانات اعتماد الفهرس لهذا الجدول، وتكون عبارة SQL كما يلي:

رمز البرنامج

إنشاء بيانات اعتماد INDEX على المستخدمين
(
اسم المستخدم،
كلمة المرور
)
يعد إنشاء فهرس أمرًا اختياريًا والأمر متروك لك. يرجى الرجوع إلى المعلومات ذات الصلة لمعرفة مزايا وعيوب الفهرسة.

ثم نضيف البيانات إلى قاعدة بيانات المستخدمين هذه. اسم الشخصية هو من اختيارك، ولكن من الأفضل استخدام اسم ذي معنى، مثل
"المسؤول" (مسؤول المستوى الأعلى)، "المدير" (المسؤول)، "العضو" (عضو منضم)، "المستخدم" (المستخدم العادي)، إلخ. على سبيل المثال:

اسم المستخدم|كلمة المرور|الأدوار
"willmove"|"pwd123"|"المسؤول،المستخدم"

"amuhouse"|"pwd123"|"User"

هي:

رمز البرنامج

--لاحظ أن '45CB41B32DCFB917CCD8614F1536D6DA' عبارة عن سلسلة مشفرة بواسطة md5 باستخدام 'pwd123'.
أدخل قيم المستخدمين (اسم المستخدم، كلمة المرور، أدوار المستخدم) ("willmove"، "45CB41B32DCFB917CCD8614F1536D6DA"، "المسؤول، المستخدم")
يذهب
أدخل قيم المستخدمين (اسم المستخدم، كلمة المرور، أدوار المستخدم) ("amuhouse"، "45CB41B32DCFB917CCD8614F1536D6DA"، "المستخدم")
يذهب

لاحظ أن الأدوار حساسة لحالة الأحرف لأنها حساسة لحالة الأحرف في ملف Web.config. نقوم الآن بإنشاء عدة صفحات ضرورية لتنفيذ آلية المصادقة الأمنية هذه.
الأول هو صفحة تسجيل دخول المستخدم Login.aspx
إذا لم تكن قد أنشأت تطبيق ويب بعد، فقم بإنشاء واحد الآن. بالطبع يمكنك أيضًا إنشاء هذه الصفحة في تطبيق ويب موجود. أفترض هنا أنه قد تم إنشاء تطبيق ويب باسم RolebasedAuth (أي مشروع في Visual Studio .Net). لقد قمت بوضع Login.aspx هذا في الدليل الجذر الخاص به، والذي يمكن الوصول إليه من خلال http://localhost/RolebasedAuth/Login.aspx .
لا يهم مكان وضع Login.aspx هذا، ولكن يجب أن يكون متاحًا للعامة.

ضمن المسار الجذري للتطبيق، نقوم بإنشاء دليلين فرعيين سريين، وهما Admin وUser.

بعد ذلك، نقوم بإنشاء نظام تسجيل دخول لمصادقة النماذج يدعم مصادقة الدور. نظرًا لأن Microsoft لا توفر آلية تنفيذ بسيطة، يتعين علينا قضاء بعض الوقت في إنشاء تذكرة المصادقة بأنفسنا. يحتاج إلى تخزين كمية صغيرة من المعلومات بالطبع، يجب أن تكون بعض الأسماء هي نفسها التي تم تكوينها في Web.config، وإلا فإن ASP.NET سيعتقد أن تذكرة المصادقة الخاصة بك غير صالحة وسيجبرك على إعادة التوجيه إلى صفحة تسجيل الدخول. نضيف عنصري تحكم TextBox إلى Login.aspx في VS.NET ونسميهما UserNameTextBox وPasswordTextBox ونضيف أيضًا زرًا ونسميه LoginButton. أضف الكود المطلوب في طريقة LoginButton_Click. على النحو التالي:

رمز البرنامج
LoginButton_Click باطل خاص (مرسل الكائن، System.EventArgs e)
{
//تهيئة مصادقة النماذج
// لاحظ أنه موجود في مساحة الاسم System.Web.Security
// إذن أضف باستخدام System.Web.Security؛
FormsAuthentication.Initialize ()؛

// إنشاء اتصال قاعدة البيانات وكائنات أوامر تشغيل قاعدة البيانات
// لاحظ أنه موجود في مساحة الاسم System.Data.SqlClient
// أضف باستخدام System.Data.SqlClient في بداية الكود
اتصال SqlConnection =
new SqlConnection("مصدر البيانات=sun-willmove;الأمان المتكامل=SSPI;الكتالوج الأولي=WebSolution;");
SqlCommand cmd = conn.CreateCommand();
cmd.CommandText = "حدد أدوار المستخدم من المستخدمين حيث اسم المستخدم=@اسم المستخدم " +
" وكلمة المرور=@كلمة المرور ";
// املأ كل معلمة
cmd.Parameters.Add("@username", SqlDbType.NVarChar, 100).القيمة =
UserNameTextBox.Text;
cmd.Parameters.Add("@password"، SqlDbType.NVarChar، 150).القيمة =
FormsAuthentication.HashPasswordForStoringInConfigFile (
كلمة المرورTextBox.Text، "md5")؛ // أو "sha1"

// تنفيذ أمر تشغيل قاعدة البيانات
conn.Open();
قارئ SqlDataReader = cmd.ExecuteReader();
إذا (القارئ.قراءة ())
{
// لتنفيذ المصادقة، قم بإنشاء تذكرة جديدة
تذكرة FormsAuthenticationTicket = FormsAuthenticationTicket جديدة (
1, // رقم إصدار التذكرة
UserNameTextBox.Text، // حامل التذكرة
DateTime.Now، // وقت تخصيص التذاكر
DateTime.Now.AddMinutes(30)، // وقت انتهاء الصلاحية
صحيح، // يتطلب ملف تعريف الارتباط الخاص بالمستخدم
Reader.GetString(0)، // بيانات المستخدم، هنا في الواقع دور المستخدم
FormsAuthentication.FormsCookiePath);// مسار ملف تعريف الارتباط صالح

// استخدم مفتاح الجهاز رمز الجهاز لتشفير ملفات تعريف الارتباط للنقل الآمن
تجزئة السلسلة = FormsAuthentication.Encrypt(ticket);
ملف تعريف ارتباط HttpCookie = HttpCookie جديد(
FormsAuthentication.FormsCookieName، // اسم ملف تعريف ارتباط المصادقة
hash); // ملف تعريف الارتباط المشفر

// اضبط وقت انتهاء صلاحية ملف تعريف الارتباط ليكون متسقًا مع وقت انتهاء صلاحية التذاكر
if (ticket.IsPersistent) cookie.Expires = Ticket.Expiration;

// إضافة ملفات تعريف الارتباط إلى استجابة طلب الصفحة
Response.Cookies.Add(cookie);

// إعادة توجيه المستخدم إلى الصفحة المطلوبة مسبقًا،
// إذا لم يتم طلب أي صفحة من قبل، قم بإعادة التوجيه إلى الصفحة الرئيسية
string returnUrl = Request.QueryString["ReturnUrl"];
if (returnUrl == null) returnUrl = "./";

// لا تستدعي طريقة FormsAuthentication.RedirectFromLoginPage.
// لأنه سيحل محل التذكرة (ملف تعريف الارتباط) التي تمت إضافتها للتو
Response.Redirect(returnUrl);
}
آخر
{
// لا تخبر المستخدم "كلمة المرور خاطئة"، فهذا يعادل إعطاء الدخيل فرصة.
// لأنهم يعرفون أن اسم المستخدم الذي أدخلوه موجود
//
ErrorLabel.Text = "اسم المستخدم أو كلمة المرور خاطئة، يرجى المحاولة مرة أخرى!";
ErrorLabel.Visible = true;
}

Reader.Close();
conn.Close();
}

رمز صفحة aspx للواجهة الأمامية هو كما يلي:

رمز البرنامج
<%@ لغة الصفحة = "c#" Codebehind = "Login.aspx.cs" AutoEventWireup = "false" Inherits = "RolebasedAuth.Login" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<أتش تي أم أل>
<الرأس>
<العنوان>تسجيل الدخول</العنوان>
<meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema" content=" http://schemas.microsoft.com/intellisense/ie5 ">
</الرأس>
<الجسم>
<form id="Form1"method="post" runat="server">
<ف>
<asp:Label id="Label1" runat="server">اسم المستخدم:</asp:Label>
<asp:TextBox id="UserNameTextBox" runat="server"></asp:TextBox></P>
<P><FONT وجه = "宋体"> </FONT>
<asp:Label id="Label2" runat="server">كلمة المرور:</asp:Label>
<asp:TextBox id="PasswordTextBox" runat="server" TextMode="Password"></asp:TextBox></P>
<ف>
<asp:Label id="ErrorLabel" runat="server" Visible="False"></asp:Label></P>
<ف>
<asp:Button id="LoginButton" runat="server" Text="Login"></asp:Button></P>
</النموذج>
</الجسم>
</HTML>

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

بدون SSL، يتم إرسال كلمة المرور الخاصة بك بنص واضح عبر الشبكة. من الممكن أن يتم سرقتها أثناء الإرسال. تشفير كلمات المرور على جانب الخادم يضمن فقط أمان تخزين كلمة المرور. يمكن العثور على المعلومات المتعلقة بـ SSL على http://www.versign.com أو http://www.thewte.com .

إذا كنت لا ترغب في تخزين كلمة المرور في قاعدة البيانات المشفرة، فيمكنك تغيير الكود أعلاه إلى
يمكن تغيير FormsAuthentication.HashPasswordForStoringInConfigFile(PasswordTextBox.Text, "md5") إلى PasswordTextBox.Text.

بعد ذلك، نحتاج إلى تعديل الملف Global.asax. إذا لم يكن تطبيق الويب الخاص بك يحتوي على هذا الملف، فيرجى النقر بزر الماوس الأيمن فوق مشروع تطبيق الويب وتحديد "إضافة->إضافة عنصر جديد...->فئة التطبيق العامة". في Global.asax أو Global.asax.cs، ابحث عن الطريقة (الوظيفة) التي تسمى Application_AuthenticationRequest. تأكد أولاً من تضمين مساحات الأسماء System.Security.Principal وSystem.Web.Security أو استخدامها، ثم قم بتعديل التعليمات البرمجية المعدلة:

رمز البرنامج
Application_AuthenticateRequest (مرسل الكائن، EventArgs e) باطل محمي
{
إذا (HttpContext.Current.User != null)
{
إذا (HttpContext.Current.User.Identity.IsAuthenticated)
{
إذا (HttpContext.Current.User.Identity هو FormsIdentity)
{
معرف هوية النماذج =
(FormsIdentity)HttpContext.Current.User.Identity;
FormsAuthenticationTicket Ticket = id.Ticket;

// احصل على بيانات المستخدم المخزنة في التذكرة، وهو في الواقع دور المستخدم هنا
سلسلة بيانات المستخدم = تذكرة. بيانات المستخدم؛
سلسلة [] الأدوار = userData.Split(',');
HttpContext.Current.User = new GenericPrincipal(id, role);
}
}
}

}

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

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

رمز البرنامج

ضمن العقدة <system.web> في ملف Web.config في الدليل الجذر لتطبيق الويب.

<وضع المصادقة = "Windows" />، قم بتغييره إلى

<وضع المصادقة = "النماذج">
<اسم النماذج = "AMUHOUSE.ASPXAUTH"
تسجيل الدخولUrl = "Login.aspx"
الحماية = "الكل"
المسار = "./" />
</المصادقة>
<الترخيص>
<السماح للمستخدمين = "*"/>
</authorization>

في الاسم = "AMUHOUSE.ASPXAUTH" أعلاه، الاسم AMUHOUSE.ASPXAUTH عشوائي. للتحكم في أذونات المستخدمين أو مجموعات المستخدمين، يمكن أن يكون لدينا طريقتان: إحداهما هي تكوين ملف Web.config في الدليل الجذر للتطبيق، والأخرى هي إنشاء ملف Web.config مستقل في الدليل السري. (قد يكون الأخير أفضل.) إذا كان الأول، فيجب أن يحتوي Web.config على المحتوى التالي (أو محتوى مشابه):

رمز البرنامج
<التكوين>
<system.web>
<وضع المصادقة = "النماذج">
<اسم النماذج = "AMUHOUSE.ASPXAUTH"
تسجيل الدخولUrl = "login.aspx"
الحماية = "الكل"
المسار = "/"/>
</المصادقة>
<الترخيص>
<السماح للمستخدمين = "*"/>
</الترخيص>
</system.web>
<مسار الموقع = "./المسؤول">
<system.web>
<الترخيص>
<!-- انتبه! ترتيب وحالة الأسطر التالية مهم جدًا! -->
<السماح بالأدوار = "المسؤول"/>
<رفض المستخدمين = "*"/>
</الترخيص>
</system.web>
</الموقع>
<مسار الموقع = "./المستخدم">
<system.web>
<الترخيص>
<!-- انتبه! ترتيب وحالة الأسطر التالية مهم جدًا! -->
<السماح بالأدوار = "المستخدم"/>
<رفض المستخدمين = "*"/>
</الترخيص>
</system.web>
</الموقع>
</التكوين>

من أجل جعل أدلة تطبيقات الويب لا تعتمد على بعضها البعض من قبل وتسهيل إعادة تسميتها أو نقلها، يمكنك اختيار تكوين ملف Web.config منفصل في كل دليل فرعي للأمان. يحتاج فقط إلى تكوين عقدة <authorization/>، كما يلي:

رمز البرنامج
<التكوين>
<system.web>
<الترخيص>
<!-- انتبه! ترتيب وحالة الأسطر التالية مهم جدًا! -->
<السماح بالأدوار = "المسؤول"/>
<رفض المستخدمين = "*"/>
</الترخيص>
</system.web>
</التكوين>

يجب التذكير مرة أخرى بأن الأدوار المذكورة أعلاه حساسة لحالة الأحرف، ويمكنك أيضًا تعديل ما ورد أعلاه من أجل:
<السماح بالأدوار = "المسؤول، المسؤول" />
إذا كنت تريد السماح بأدوار متعددة أو رفض الوصول إلى هذا الدليل، فيمكنك فصلها بفواصل، مثل:
<السماح بالأدوار = "المسؤول، العضو، المستخدم" />
<deny users="*" />

في هذه المرحلة، قمنا بتكوين آلية مصادقة أمان تعتمد على الدور لموقع الويب. يمكنك ترجمة برنامجك أولاً، ثم محاولة الوصول إلى دليل سري، مثل http://localhost/RolebasedAuth/Admin ، وفي ذلك الوقت ستتم إعادة توجيهك إلى صفحة تسجيل دخول المستخدم. إذا قمت بتسجيل الدخول بنجاح وكان لدورك حقوق الوصول إلى هذا الدليل، فسوف تعود إلى هذا الدليل. قد يكون هناك مستخدمين (أو متطفلين) يحاولون الدخول إلى الدليل السري. يمكننا استخدام الجلسة لتخزين عدد المرات التي قام فيها المستخدم بتسجيل الدخول. إذا تجاوز العدد رقمًا معينًا، فلن يُسمح للمستخدم بتسجيل الدخول، وسيتم عرض "لقد رفض النظام طلب تسجيل الدخول الخاص بك!"

نناقش أدناه كيفية جعل عناصر التحكم في الويب تعرض محتوى مختلفًا بناءً على أدوار المستخدم.

في بعض الأحيان يكون من الأفضل عرض المحتوى بناءً على دور المستخدم، لأنك ربما لا ترغب في إنشاء مجموعة من الصفحات تحتوي على الكثير من المحتوى المكرر للعديد من الأدوار المختلفة (مجموعات المستخدمين). في مثل هذا الموقع، يمكن أن تتعايش حسابات مستخدمين مختلفة، ويمكن لحسابات المستخدمين المدفوعة الوصول إلى محتوى إضافي مدفوع. مثال آخر هو الصفحة التي ستعرض زر "أدخل المسؤول" الذي يرتبط بصفحة المسؤول إذا كان المستخدم الحالي في دور "المسؤول". سوف نقوم بتنفيذ هذه الصفحة الآن.
تطبق فئة GenericPrincipal التي استخدمناها أعلاه واجهة IPincipal. تحتوي هذه الواجهة على طريقة تسمى IsInRole ()، والمعلمة الخاصة بها عبارة عن سلسلة. إذا أردنا عرض المحتوى للمستخدمين الذين قاموا بتسجيل الدخول والذين يكون دورهم "المسؤول"، فيمكننا إضافة الكود التالي في Page_Load:

كود البرنامج
إذا (User.IsInRole("المسؤول"))
AdminLink.Visible = true؛

رمز الصفحة بالكامل كما يلي (للتبسيط، يتم أيضًا كتابة رمز الخلفية في صفحة aspx):

رمز البرنامج
<أتش تي أم أل>
<الرأس>
<العنوان>مرحبًا! </العنوان>
<script runat="server">
Page_Load (مرسل الكائن، EventArgs e) باطلة محمية
{
إذا (User.IsInRole("المسؤول"))
AdminLink.Visible = true;
آخر
AdminLink.Visible = false;
}
</script>
</الرأس>
<الجسم>
<h2>مرحبًا! </h2>
<p>مرحبًا بكم في Amu House http://amuhouse.com/ ^_^</p>
<asp:HyperLink id = "AdminLink" runat = "الخادم"
Text="الصفحة الرئيسية للمسؤول" NavigateUrl="./Admin"/>
</الجسم>
</html>

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

رمز البرنامج
Page_Load باطلة محمية (مرسل الكائن، System.EventArgs e)
{

إذا (User.IsInRole("المسؤول"))
{
AdminLink.Text = "المسؤول يرجى الدخول";
AdminLink.NavigateUrl="./Admin";
}
وإلا إذا (User.IsInRole("المستخدم"))
{
AdminLink.Text = "يرجى إدخال المستخدمين المسجلين";
AdminLink.NavigateUrl="./User"

}
آخر
{
AdminLink.Text = "الرجاء تسجيل الدخول";
AdminLink.NavigateUrl="Login.aspx?ReturnUrl=" + Request.Path;
}

}

هنا، من خلال تعيين متغير QueryString المسمى ReturnUrl، يمكننا إعادة المستخدم إلى الصفحة الحالية بعد تسجيل الدخول بنجاح.

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

مُرفَق:
نموذج للكود المصدري للمشروع لهذه المقالة: