กลไกการตรวจสอบความปลอดภัยของฟอร์มตามบทบาท ASP.NET

ผู้เขียน: วิลมูฟ && ฮีธ สจ๊วต
หน้าแรก: http://www.amuhouse.com
อีเมล์: [email protected]
หมายเหตุ: ฉันเพิ่งเรียนรู้ ASP.NET เมื่อสองเดือนก่อน ฉันเห็นบทความชื่อ Role-based Security with Forms Authentication บน codeproject.com และพบว่ามีประโยชน์มาก ตอนนั้นฉันอยากแปลเป็นภาษาจีน อย่างไรก็ตาม การแปลโดยตรงนั้นน่าเบื่อมาก ในช่วงสองวันที่ผ่านมา ฉันอ้างอิงบทความนี้โดย Heath Stewart และจากความเข้าใจของฉันเอง ฉันจึงเขียนเป็นภาษาจีนตามแนวคิดและสำนวนของฉันเอง สิ่งที่แนบมาด้วยคือแอปพลิเคชันเว็บสาธิตที่ฉันสร้างขึ้นสำหรับบทความนี้
หากมีความเข้าใจผิดใด ๆ โปรดเขียนเพื่อชี้ให้เห็นหรือแสดงความคิดเห็น

ป.ล. สแปมน่ารำคาญมาก โปรดแสดงความเคารพ

บทความต้นฉบับอยู่ที่ http://www.codeproject.com/aspnet/formsroleauth.asp
ผู้เขียนต้นฉบับ ฮีธ สจ๊วต

สรุป:
ASP.NET มีกลไกการรับรองความถูกต้องตามบทบาท แต่การสนับสนุนบทบาทไม่สมบูรณ์ บทความนี้พยายามอธิบายวิธีการใช้และใช้กลไกการรับรองความถูกต้องตามบทบาทผ่านตัวอย่างบางส่วน

บทนำ:

การรับรองความถูกต้องของแบบฟอร์มใน ASP.NET เป็นคุณลักษณะที่มีประสิทธิภาพมากซึ่งต้องใช้รหัสเพียงเล็กน้อยเพื่อใช้ระบบการตรวจสอบความปลอดภัยที่ไม่ขึ้นกับแพลตฟอร์มอย่างง่าย
อย่างไรก็ตาม หากคุณต้องการกลไกการตรวจสอบความถูกต้องที่ซับซ้อนและมีประสิทธิภาพมากขึ้น คุณจะต้องใช้ประโยชน์จากความยืดหยุ่นของมันโดยการแบ่งผู้ใช้จำนวนมากออกเป็นกลุ่มผู้ใช้ Windows Integrated Authentication มีกลไกการตรวจสอบสิทธิ์นี้ แต่ใช้ NTLM ซึ่งเป็น Windows NT LAN Manager ดังนั้นจึงไม่ใช่ข้ามแพลตฟอร์ม ขณะนี้ผู้คนใช้ระบบ Linux มากขึ้นเรื่อยๆ และมีผู้ใช้เบราว์เซอร์ Mozilla Forefox เพิ่มมากขึ้นเรื่อยๆ เราไม่สามารถกันคนเหล่านี้ออกไปได้อย่างแน่นอน ดังนั้นเราจึงกำลังมองหากลไกการตรวจสอบสิทธิ์แบบอื่น มีสองตัวเลือก: หนึ่งคือการแบ่งเว็บไซต์ออกเป็นหลายพื้นที่และจัดเตรียมหน้าเข้าสู่ระบบหลายหน้า โดยบังคับให้ผู้ใช้ลงทะเบียนและเข้าสู่ระบบทีละหน้า อีกทางหนึ่งคือจัดกลุ่มผู้ใช้และจำกัดสิทธิ์การเข้าถึงของกลุ่มผู้ใช้เฉพาะเจาะจงเฉพาะบางหน้า หรือพื้นที่ อย่างหลังเป็นทางเลือกที่ดีกว่าอย่างแน่นอน เราสามารถบรรลุฟังก์ชันนี้ได้โดยการกำหนดบทบาทให้กับผู้ใช้แต่ละราย

Microsoft ทิ้งกลไกการรับรองความถูกต้องตามบทบาทในการรับรองความถูกต้องของแบบฟอร์มสำหรับแพลตฟอร์ม .NET แต่เราจำเป็นต้องนำไปใช้เอง บทความนี้มุ่งมั่นที่จะครอบคลุมสิ่งพื้นฐานบางอย่างเกี่ยวกับกลไกการตรวจสอบสิทธิ์ตามบทบาทในการตรวจสอบสิทธิ์ของแบบฟอร์ม เช่น แนวคิด การใช้งาน วิธีการนำไปใช้ในเว็บแอปพลิเคชัน ฯลฯ

การเตรียมการที่จำเป็น:
ก่อนอื่น เราต้องสร้างฐานข้อมูล โครงการแอปพลิเคชันเว็บ ไดเร็กทอรีที่เป็นความลับหลายรายการซึ่งมีระดับความปลอดภัยที่แตกต่างกัน และเพจ ASP.NET หลายเพจ แน่นอนว่าคุณสามารถเพิ่มสิ่งเหล่านี้ลงในโปรเจ็กต์เว็บแอปพลิเคชันที่คุณมีอยู่ได้

1. หากต้องการสร้างฐานข้อมูล

คุณต้องเลือกระบบจัดการฐานข้อมูล DBMS ที่คุณต้องการใช้ก่อน บทความนี้ใช้ SQL Server 2000

ในฐานข้อมูลของโครงการแอปพลิเคชันจริง โดยปกติแล้วจะมีตารางข้อมูลผู้ใช้ Users ซึ่งอาจรวมถึงแท็กเฉพาะของผู้ใช้: UserID, ชื่อผู้ใช้: ชื่อผู้ใช้, รหัสผ่าน: รหัสผ่าน, ที่อยู่อีเมลของผู้ใช้: อีเมล, เมืองของผู้ใช้: เมือง และจำนวน ผู้ใช้เข้าสู่ระบบ LoginCount ฯลฯ คุณสามารถกำหนดบทบาทให้กับผู้ใช้ได้โดยการสร้างตารางข้อมูล UserInRoles (โดยทั่วไปจะประกอบด้วยสองฟิลด์ ชื่อผู้ใช้: ชื่อผู้ใช้ บทบาทผู้ใช้: UserRoles)

เพื่อความเรียบง่าย ฉันจึงสร้างเฉพาะตารางข้อมูลผู้ใช้ซึ่งมี 3 ฟิลด์ ได้แก่ ชื่อผู้ใช้ ชื่อผู้ใช้ รหัสผ่าน รหัสผ่าน และบทบาทของผู้ใช้ UserRoles ก่อนที่จะสร้างตาราง คุณต้องเลือกฐานข้อมูลหรือสร้างฐานข้อมูลใหม่ ในการสร้างฐานข้อมูลใหม่ชื่อ WebSolution ต้องใช้คำสั่ง SQL แบบง่ายเท่านั้น:

รหัสโปรแกรม
สร้างฐานข้อมูล WebSolution

หากต้องการเลือกฐานข้อมูลชื่อ msdb

ใน GO

รหัสโปรแกรม
ใช้ msdb
ไป

ต่อไป เราสร้างตารางข้อมูลผู้ใช้ที่เพิ่งกล่าวถึง สคริปต์ SQL เป็นดังนี้:

รหัสโปรแกรม

สร้างผู้ใช้ตาราง
-
ชื่อผู้ใช้ nvarchar (100) ข้อ จำกัด PK_UserName คีย์หลัก
รหัสผ่าน nvarchar(150)
บทบาทผู้ใช้ nvarchar (100)
)

สามารถสร้างดัชนีข้อมูลรับรองสำหรับตารางนี้ได้ คำสั่ง SQL เป็นดังนี้:

รหัสโปรแกรม

สร้างข้อมูลรับรอง INDEX ON ผู้ใช้
-
ชื่อผู้ใช้,
รหัสผ่าน
-
การสร้างดัชนีเป็นทางเลือกและขึ้นอยู่กับคุณ โปรดดูข้อมูลที่เกี่ยวข้องสำหรับข้อดีและข้อเสียของการจัดทำดัชนี

จากนั้นเราจะเพิ่มข้อมูลลงในฐานข้อมูลผู้ใช้นี้ ชื่อตัวละครเป็นชื่อของคุณเอง แต่ควรใช้ชื่อที่มีความหมาย เช่น
"ผู้ดูแลระบบ" (ผู้ดูแลระบบระดับบนสุด), "ผู้จัดการ" (ผู้ดูแลระบบ), "สมาชิก" (สมาชิกที่เข้าร่วม), "ผู้ใช้" (ผู้ใช้ทั่วไป) ฯลฯ ตัวอย่างเช่น:

ชื่อผู้ใช้|รหัสผ่าน|บทบาท
"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 นี้จะอยู่ที่ใด แต่ต้องสามารถเข้าถึงได้โดยสาธารณะ

ภายใต้เส้นทางรูทของแอปพลิเคชัน เราสร้างไดเร็กทอรีย่อยลับสองรายการ ได้แก่ ผู้ดูแลระบบและผู้ใช้

ต่อไป เราจะสร้างระบบเข้าสู่ระบบการรับรองความถูกต้องของแบบฟอร์มที่รองรับการรับรองความถูกต้องของบทบาท เนื่องจาก Microsoft ไม่มีกลไกการใช้งานที่เรียบง่าย เราจึงต้องใช้เวลาพอสมควรในการสร้างตั๋วการตรวจสอบสิทธิ์ด้วยตนเอง จำเป็นต้องจัดเก็บข้อมูลจำนวนเล็กน้อย แน่นอนว่า บางชื่อจะต้องเหมือนกับชื่อที่กำหนดค่าใน Web.config มิฉะนั้น ASP.NET จะคิดว่าตั๋วการรับรองความถูกต้องของคุณไม่ถูกต้องและบังคับให้คุณเปลี่ยนเส้นทางไปยังหน้าเข้าสู่ระบบ เราเพิ่มตัวควบคุมกล่องข้อความสองตัวลงใน Login.aspx ใน VS.NET และตั้งชื่อเป็น UserNameTextBox และ PasswordTextBox นอกจากนี้ เรายังเพิ่มปุ่มและตั้งชื่อเป็น LoginButton คลิกเพื่อป้อนโค้ดพื้นหลัง เพิ่มรหัสที่จำเป็นในเมธอด LoginButton_Click ดังต่อไปนี้:

รหัสโปรแกรม
โมฆะส่วนตัว LoginButton_Click (ผู้ส่งวัตถุ System.EventArgs e)
-
//เตรียมใช้งาน FormsAuthentication
// โปรดทราบว่าอยู่ในเนมสเปซ System.Web.Security
// ดังนั้นให้เพิ่มการใช้ System.Web.Security ไว้ที่ตอนต้นของโค้ด
FormsAuthentication.Initialize ();

// สร้างการเชื่อมต่อฐานข้อมูลและวัตถุคำสั่งการดำเนินการฐานข้อมูล
// โปรดทราบว่าอยู่ในเนมสเปซ System.Data.SqlClient
// ดังนั้นให้เพิ่มการใช้ System.Data.SqlClient ไว้ที่ตอนต้นของโค้ด
SqlConnection เชื่อมต่อ =
ใหม่ SqlConnection("แหล่งข้อมูล=sun-willmove;integrated security=SSPI;Initial Catalog=WebSolution;");
SqlCommand cmd = conn.CreateCommand();
cmd.CommandText = "เลือก UserRoles จากผู้ใช้ โดยที่ UserName=@username " +
"และ รหัสผ่าน=@รหัสผ่าน ";
// กรอกแต่ละพารามิเตอร์
cmd.Parameters.Add("@ชื่อผู้ใช้", SqlDbType.NVarChar, 100).Value =
ชื่อผู้ใช้TextBox.Text;
cmd.Parameters.Add("@password", SqlDbType.NVarChar, 150).Value =
FormsAuthentication.HashPasswordForStoringInConfigFile(
PasswordTextBox.Text, "md5"); // หรือ "sha1"

// ดำเนินการคำสั่งการดำเนินการฐานข้อมูล
conn.เปิด();
เครื่องอ่าน SqlDataReader = cmd.ExecuteReader();
ถ้า (reader.Read())
-
// หากต้องการใช้การรับรองความถูกต้อง ให้สร้างตั๋วใหม่
ตั๋ว FormsAuthenticationTicket = ใหม่ FormsAuthenticationTicket(
1, // หมายเลขเวอร์ชันตั๋ว
UserNameTextBox.Text, // ผู้ถือตั๋ว
DateTime.Now, //ถึงเวลาจัดสรรตั๋ว
DateTime.Now.AddMinutes(30), //เวลาหมดอายุ
จริง // ต้องมีคุกกี้ของผู้ใช้
reader.GetString(0), // User data นี่คือบทบาทของผู้ใช้จริงๆ
FormsAuthentication.FormsCookiePath);//เส้นทางคุกกี้ที่ถูกต้อง

//ใช้รหัสเครื่องรหัสเครื่องเพื่อเข้ารหัสคุกกี้เพื่อการส่งข้อมูลที่ปลอดภัย
แฮชสตริง = FormsAuthentication.Encrypt (ตั๋ว);
คุกกี้ HttpCookie = HttpCookie ใหม่ (
FormsAuthentication.FormsCookieName, // ชื่อของคุกกี้การรับรองความถูกต้อง
hash); // คุกกี้ที่เข้ารหัส

// ตั้งเวลาหมดอายุของคุกกี้ให้สอดคล้องกับเวลาหมดอายุของตั๋ว
if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;

//เพิ่มคุกกี้ในการตอบกลับคำขอของเพจ
Response.Cookies.Add(cookie);

//เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าที่ร้องขอก่อนหน้านี้
// หากไม่มีการร้องขอเพจใด ๆ มาก่อน ให้เปลี่ยนเส้นทางไปที่หน้าแรก
string returnUrl = Request.QueryString["ReturnUrl"];
ถ้า (returnUrl == null) returnUrl = "./";

// อย่าเรียกเมธอด FormsAuthentication.RedirectFromLoginPage
// เพราะมันจะมาแทนที่ตั๋ว (คุกกี้) ที่เพิ่งเพิ่มเข้าไป
Response.Redirect (returnUrl);
-
อื่น
-
// อย่าบอกผู้ใช้ว่า "รหัสผ่านไม่ถูกต้อง" นี่เทียบเท่ากับการให้โอกาสผู้บุกรุก
// เพราะพวกเขารู้ว่ามีชื่อผู้ใช้ที่พวกเขาป้อนอยู่
-
ErrorLabel.Text = "ชื่อผู้ใช้หรือรหัสผ่านไม่ถูกต้อง โปรดลองอีกครั้ง!";
ErrorLabel.Visible = จริง;
}

reader.ปิด();
conn.ปิด();
}

รหัสหน้า aspx ส่วนหน้าเป็นดังนี้:

รหัสโปรแกรม
<%@ ภาษาเพจ = "c#" Codebehind = "Login.aspx.cs" AutoEventWireup = "false" สืบทอด = "RolebasedAuth.Login" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<หัว>
<title>เข้าสู่ระบบ</title>
<meta name = "เครื่องกำเนิดไฟฟ้า" เนื้อหา = "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 ">
</HEAD>
<ร่างกาย>
<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 face="宋体"> </FONT>
<asp:Label id="Label2" runat="server">รหัสผ่าน:</asp:Label>
<asp:TextBox id="PasswordTextBox" runat="server" TextMode="รหัสผ่าน"></asp:TextBox></P>
<ป>
<asp:Label id = "ErrorLabel" runat = "เซิร์ฟเวอร์" Visible = "False"></asp:Label></P>
<ป>
<asp:Button id="LoginButton" runat="server" Text="เข้าสู่ระบบ"></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 = ticket.UserData;
string[] บทบาท = userData.Split(',');
HttpContext.Current.User = GenericPrincipal ใหม่ (id, บทบาท);
-
-
}

}

ตั๋วการตรวจสอบสิทธิ์ (ชื่อผู้ใช้และรหัสผ่าน) จะไม่ถูกจัดเก็บเป็นส่วนหนึ่งของคุกกี้ และไม่สามารถจัดเก็บได้เนื่องจากผู้ใช้สามารถแก้ไขคุกกี้ของตนได้
ในความเป็นจริง FormsAuthentication ใช้รหัสเครื่องของคุณ (โดยปกติจะอยู่ใน machine.config) เพื่อเข้ารหัสตั๋ว (FormsAuthenticationTicket) เราใช้ UserData เพื่อจัดเก็บบทบาทของผู้ใช้และสร้างข้อมูลรับรองใหม่ เมื่อสร้างข้อมูลประจำตัวแล้ว ข้อมูลจะถูกเพิ่มในบริบทปัจจุบัน (เช่น HttpContext) เพื่อให้สามารถใช้เพื่อดึงบทบาทของผู้ใช้

ต่อไป เราตั้งค่าไดเร็กทอรีลับ (นั่นคือ "ไดเร็กทอรีความปลอดภัย" ซึ่งเป็นไดเร็กทอรีที่มีเฉพาะผู้ใช้ที่ระบุเท่านั้น เช่น ผู้ดูแลระบบเท่านั้นที่มีสิทธิ์ในการเข้าถึง) ขั้นแรกให้ตรวจสอบว่ามีไฟล์ Web.config ในไดเร็กทอรีรากของเว็บแอปพลิเคชันของคุณหรือไม่ หากไม่มี ให้สร้างขึ้นใหม่ คุณยังสามารถสร้างไฟล์ Web.config ในไดเร็กทอรีย่อยของคุณได้ แน่นอนว่าไฟล์ Web.config นี้ถูกจำกัดไว้ (ไม่สามารถตั้งค่าพารามิเตอร์บางตัวได้)

โค้ดโปรแกรม

ใต้โหนด <system.web> ในไฟล์ Web.config ในไดเร็กทอรีรากของแอปพลิเคชันเว็บ

<authentication mode="Windows" /> เปลี่ยนเป็น

<authentication mode="Forms">
<ชื่อแบบฟอร์ม = "AMUHOUSE.ASPXAUTH"
เข้าสู่ระบบ Url = "เข้าสู่ระบบ. aspx"
การป้องกัน = "ทั้งหมด"
เส้นทาง = "./" />
</การรับรองความถูกต้อง>
<การอนุญาต>
<อนุญาตให้ผู้ใช้ = "*"/>
</authorization>

ใน name="AMUHOUSE.ASPXAUTH" ด้านบน ชื่อ AMUHOUSE.ASPXAUTH นั้นเป็นชื่อที่กำหนดเอง ในการควบคุมสิทธิ์ของผู้ใช้หรือกลุ่มผู้ใช้ เราสามารถมีสองวิธี วิธีหนึ่งคือการกำหนดค่าไฟล์ Web.config ในไดเร็กทอรีรากของแอปพลิเคชัน และอีกวิธีหนึ่งคือการสร้างไฟล์ Web.config อิสระในไดเร็กทอรีลับ (อย่างหลังอาจจะดีกว่า) ถ้าเป็นอย่างแรก Web.config ควรมีเนื้อหาต่อไปนี้ (หรือเนื้อหาที่คล้ายกัน):

รหัสโปรแกรม
<การกำหนดค่า>
<system.เว็บ>
<โหมดการรับรองความถูกต้อง = "แบบฟอร์ม">
<ชื่อแบบฟอร์ม = "AMUHOUSE.ASPXAUTH"
เข้าสู่ระบบ Url = "login.aspx"
การป้องกัน = "ทั้งหมด"
เส้นทาง = "/"/>
</การรับรองความถูกต้อง>
<การอนุญาต>
<อนุญาตให้ผู้ใช้ = "*"/>
</การอนุญาต>
</system.เว็บ>
<เส้นทางตำแหน่ง="./ผู้ดูแลระบบ">
<system.เว็บ>
<การอนุญาต>
<!-- โปรดทราบ! ลำดับและตัวพิมพ์ของบรรทัดต่อไปนี้มีความสำคัญมาก! -
<อนุญาตบทบาท = "ผู้ดูแลระบบ"/>
<ปฏิเสธผู้ใช้ = "*"/>
</การอนุญาต>
</system.เว็บ>
</ตำแหน่ง>
<เส้นทางตำแหน่ง="./ผู้ใช้">
<system.เว็บ>
<การอนุญาต>
<!-- โปรดทราบ! ลำดับและตัวพิมพ์ของบรรทัดต่อไปนี้มีความสำคัญมาก! -
<อนุญาตบทบาท = "ผู้ใช้"/>
<ปฏิเสธผู้ใช้ = "*"/>
</การอนุญาต>
</system.เว็บ>
</ตำแหน่ง>
</การกำหนดค่า>

เพื่อทำให้ไดเร็กทอรีของเว็บแอปพลิเคชันไม่ต้องพึ่งพากันมาก่อน และช่วยให้เปลี่ยนชื่อหรือย้ายได้ง่ายขึ้น คุณสามารถเลือกกำหนดค่าไฟล์ Web.config แยกต่างหากในแต่ละไดเร็กทอรีย่อยด้านความปลอดภัยได้ เพียงแต่ต้องกำหนดค่าโหนด <authorization/> ดังต่อไปนี้:

รหัสโปรแกรม
<การกำหนดค่า>
<system.เว็บ>
<การอนุญาต>
<!-- โปรดทราบ! ลำดับและตัวพิมพ์ของบรรทัดต่อไปนี้มีความสำคัญมาก! -
<อนุญาตบทบาท = "ผู้ดูแลระบบ"/>
<ปฏิเสธผู้ใช้ = "*"/>
</การอนุญาต>
</system.เว็บ>
</การกำหนดค่า>

ควรได้รับการเตือนอีกครั้งว่าบทบาทข้างต้นคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ เพื่อความสะดวก คุณสามารถแก้ไขด้านบนเป็น:
<อนุญาตบทบาท = "ผู้ดูแลระบบ ผู้ดูแลระบบ" />
หากคุณต้องการอนุญาตหรือปฏิเสธการเข้าถึงหลายบทบาทในไดเร็กทอรีนี้ คุณสามารถแยกบทบาทเหล่านั้นด้วยเครื่องหมายจุลภาค เช่น:
<อนุญาตบทบาท = "ผู้ดูแลระบบ สมาชิก ผู้ใช้" />
<deny users="*" />

ณ จุดนี้ เราได้กำหนดค่ากลไกการตรวจสอบความปลอดภัยตามบทบาทสำหรับเว็บไซต์ คุณสามารถคอมไพล์โปรแกรมของคุณก่อน จากนั้นจึงลองเข้าถึงไดเร็กทอรีลับ เช่น http://localhost/RolebasedAuth/Admin ซึ่งในเวลานั้นคุณจะถูกเปลี่ยนเส้นทางไปยังหน้าเข้าสู่ระบบของผู้ใช้ หากคุณเข้าสู่ระบบสำเร็จและบทบาทของคุณมีสิทธิ์เข้าถึงไดเร็กทอรีนี้ คุณจะกลับสู่ไดเร็กทอรีนี้ อาจมีผู้ใช้ (หรือผู้บุกรุก) พยายามเข้าสู่ไดเร็กทอรีที่เป็นความลับ เราสามารถใช้เซสชันเพื่อจัดเก็บจำนวนครั้งที่ผู้ใช้เข้าสู่ระบบ หากจำนวนเกินจำนวนที่กำหนด ผู้ใช้จะไม่ได้รับอนุญาตให้เข้าสู่ระบบ และข้อความ "ระบบปฏิเสธคำขอเข้าสู่ระบบของคุณ!" จะปรากฏขึ้น

ด้านล่างนี้ เราจะพูดถึงวิธีทำให้การควบคุมเว็บแสดงเนื้อหาที่แตกต่างกันตามบทบาทของผู้ใช้

บางครั้ง อาจเป็นการดีกว่าที่จะแสดงเนื้อหาตามบทบาทของผู้ใช้ เนื่องจากคุณอาจไม่ต้องการสร้างเพจจำนวนมากที่มีเนื้อหาซ้ำกันจำนวนมากสำหรับบทบาทต่างๆ มากมาย (กลุ่มผู้ใช้) บนไซต์ดังกล่าว บัญชีผู้ใช้ต่างๆ สามารถอยู่ร่วมกันได้ และบัญชีผู้ใช้แบบชำระเงินสามารถเข้าถึงเนื้อหาที่ต้องชำระเงินเพิ่มเติมได้ อีกตัวอย่างหนึ่งคือหน้าที่จะแสดงปุ่ม "เข้าสู่ผู้ดูแลระบบ" ซึ่งเชื่อมโยงกับหน้าผู้ดูแลระบบหากผู้ใช้ปัจจุบันอยู่ในบทบาท "ผู้ดูแลระบบ" เราจะดำเนินการหน้านี้ทันที
คลาส GenericPrincipal ที่เราใช้ข้างต้นใช้อินเทอร์เฟซ IPincipal อินเทอร์เฟซนี้มีเมธอดที่เรียกว่า IsInRole() และพารามิเตอร์ของมันคือสตริงนี้เป็นบทบาทของผู้ใช้ที่ต้องตรวจสอบ หากเราต้องการแสดงเนื้อหาให้กับผู้ใช้ที่ล็อกอินซึ่งมีบทบาทเป็น "ผู้ดูแลระบบ" เราสามารถเพิ่มโค้ดต่อไปนี้ใน Page_Load:

รหัสโปรแกรม
ถ้า (User.IsInRole("ผู้ดูแลระบบ"))
AdminLink.Visible = true;

โค้ดของเพจทั้งหมดเป็นดังนี้ (เพื่อความง่าย โค้ดพื้นหลังจะถูกเขียนในหน้า aspx ด้วย):

รหัสโปรแกรม
<html>
<หัว>
<title>ยินดีต้อนรับ! </ชื่อเรื่อง>
<script runat="เซิร์ฟเวอร์">
โมฆะที่ได้รับการป้องกัน Page_Load (ผู้ส่งวัตถุ EventArgs e)
-
ถ้า (User.IsInRole("ผู้ดูแลระบบ"))
AdminLink.Visible = จริง;
อื่น
AdminLink.Visible = เท็จ;
-
</สคริปต์>
</หัว>
<ร่างกาย>
<h2>ยินดีต้อนรับ! </h2>
<p>ยินดีต้อนรับสู่บ้านอามู http://amuhouse.com/ ^_^</p>
<asp:HyperLink id = "AdminLink" runat = "เซิร์ฟเวอร์"
Text="หน้าแรกของผู้ดูแลระบบ" NavigateUrl="./Admin"/>
</ร่างกาย>
</html>

ด้วยวิธีนี้ การควบคุมไฮเปอร์ลิงก์ที่เชื่อมโยงกับไดเร็กทอรีผู้ดูแลระบบจะแสดงต่อผู้ใช้ที่มีบทบาทเป็นผู้ดูแลระบบเท่านั้น คุณยังสามารถให้ลิงก์ไปยังหน้าเข้าสู่ระบบแก่ผู้ใช้ที่ไม่ได้เข้าสู่ระบบได้ เช่น:

รหัสโปรแกรม
โมฆะที่ได้รับการป้องกัน 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 = " + คำขอเส้นทาง;
}

}

ที่นี่ โดยการตั้งค่าตัวแปร QueryString ชื่อ ReturnUrl เราสามารถส่งผู้ใช้กลับไปยังหน้าปัจจุบันหลังจากเข้าสู่ระบบสำเร็จ

สรุป:
บทความนี้ใช้เพื่อช่วยให้คุณเข้าใจถึงความสำคัญและการปฏิบัติจริงของกลไกการรักษาความปลอดภัยตามบทบาท และยังใช้ ASP.NET เพื่อใช้กลไกการรักษาความปลอดภัยตามบทบาท ไม่ใช่กลไกที่ยากต่อการนำไปใช้ แต่อาจต้องอาศัยความรู้บางประการเกี่ยวกับข้อมูลประจำตัวของผู้ใช้ วิธีตรวจสอบสิทธิ์ผู้ใช้ และวิธีตรวจสอบสิทธิ์ผู้ใช้ที่ได้รับอนุญาต ฉันจะมีความสุขมากถ้าคุณพบว่ามันมีประโยชน์ ฉันหวังว่าสิ่งนี้จะช่วยแนะนำคุณในการใช้การรับรองความถูกต้องด้านความปลอดภัยของแบบฟอร์มตามบทบาทในเว็บไซต์ของคุณ

ที่แนบมา:
ตัวอย่างซอร์สโค้ดโครงการสำหรับบทความนี้: