1. Use the Forms to verify storage user custom information
Forms Verify that the internal mechanism is saved in a cookie-based ticket FormAuthenticationalTicket after encrypted user data, so it should be relatively secure. In addition to this ticket stores its own information, .NET has left the user's free administration, which is Userdata.
UserData can be used to store String type information, and also enjoy the encryption protection provided by Forms verification. When we need this information, it can also be obtained by simple GET methods, taking care of security and ease of use, to save some must Sensitive information is still very useful.
Let's see how to use UserData, then give an example of actual use.
// Create a new bill, the customer will be credited to the ticket ip of userdataFormsAuthenticationTicket ticket = new FormsAuthenticationTicket (1, userName.Text, DateTime.Now, DateTime.Now.AddMinutes (30), false, Request.UserHostAddress); // will ticket encrypted string authTicket = FormsAuthentication.Encrypt (ticket); // save the ticket is encrypted cookieHttpCookie coo = new HttpCookie (FormsAuthentication.FormsCookieName, authTicket); // Add a new use of cookieResponse.Cookies.Add userdata (COO) Next is a method for one of the overload of the FormSauthenticationalTicket Configuration function. Name is associated with authentication tickets. IssueDate cookie issued time. Expiration Cookie's expiration date. IsPersistent If the cookie is lasting, true; otherwise false. UserData defines the user-defined data stored in cookies
It is also very simple to use UserData. The Ticket attribute of FormSidentity provides access to the current bill. After obtaining the ticket, you can use the userData property to access saved information, of course, is decrypted. (System.Web.Security.FormSidentity) this.context.user.Identity) .ticket.userdata
Here is a specific application.
Since Forms verification is made through cookie, it needs to pass a bill for work. Although the bill is encrypted, the content inside is not visible, but this does not prevent someone from using a fake identity (just like we can take other people's key to open the lock), more common is the different IP users Unsaped channels intercepted this bill and then use it for some security activities.
One of the ways to solve this problem is to use SSL to deliver information.
But if you can't use SSL? We can determine whether IP and tickets match, if the requestible IP is the IP of the issuance of the bill, there is no problem, otherwise it is destroyed.
To this end, we need to save the IP of the user when you log in, so that you can verify that the IP of the subsequent request and the initial IP are verified at any time in the later request. The best place to save this sensitive IP is of course UserData, and verification time is when the AuthenticateRequest event occurs, that is, the Application_AuthenticateRequest method defined in Global.aspx.cs. The above example actually has been saved in UserData in UserData, and below is the process of verification.
if (this.Request.IsAuthenticated) {if (((System.Web.Security.FormsIdentity) this.Context.User.Identity) .Ticket.UserData! = this.Request.UserHostAddress) {System.Security.Principal.GenericIdentity gi = new System.Security.Principal.GenericIdentity ( "", ""); string [] rolesi = {}; System.Security.Principal.GenericPrincipal gpi = new System.Security.Principal.GenericPrincipal (gi, rolesi); this. Context.user = gpi;}}
This will not be able to log in to genericIdentity and Roles via genericIdentity and Roles so that it will force users to log in. In order to test this method, you can change the condition to the equal, how to look :)
This method also has a deficiency, specifically:
1. Users using the same agent will have the same IP, so you can't prevent such counterfeit attacks.
2. If the user uses dynamic IP, it may cause normal users to be destroyed by us. However, in general, this approach is still more feasible.
2. Use the security feature to match the Forms to verify the security operation.
PrincipalPermissionAttribute can match the Forms to verify the role or user-based security verification, which cannot be used for assembly levels. Its action range can be class or specific method. To see a simple example.
[PrincipalPermission (SecurityAction.Demand, User = "Notus")] public class Test: BasePage {private void Page_Load (object sender, System.EventArgs e) {try {this.sayHello (); this.sayHello2 ();} catch ( Exception ex) {Response.Write (ex.ToString ());}} private void sayHello () {Response.Write ( "hello world!"); "! hello PrincipalPermissionAttribute"} private void sayHello2 () {Response.Write ( );} # Region Web Form Designer Generated Code Override Protected Void OnInit (Eventargs E) {//// Codegen: This call is required for the ASP.NET Web Form Designer. //InitializeComponent ();Base.onit (E ); }///
Next, we change the scope of the characteristics. Moving the property declaration to the SayHello2 method, after recoiling, then running the program after running to the SayHello2 method, System.Security.securityException. This shows that the scope of security is reduced to the method level.
This feature can be performed by setting User and Role for security protection based on user and role. In addition, the first parameter used is the securityAction enumeration, which sets specific protection levels or measures. This Demand like us is as required to call all advanced caller in the calling stack has been awarded the permissions specified by the current authority object.
Here is an example of MSDN
Example
The following example illustrates how you can use PrincipalPermission in a declaration to ask the current user as Bob and belong to the Supervisor role. [PrincipalPermissionAttribute (SecurityAction.Demand, Name = "Bob", role = "supervisor")] The following example shows how to ask the current user's identity as Bob, which is independent of the role member condition. [PrincipalPermissionAttribute (SecurityAction.Demand, Name = "Bob")] The following example shows how to authenticate the user only. [PrincipalPermissionatTribute (securityAction.demand, Authenticated = true)]
Then, the user and role inside are integrated with Forms, accordingly, we can use PrincipalPermissionattribute in some important classes or methods to arrament their own programs to home.
In fact, the role of this feature is far more than this, more detailed information can be found in MSDN.
