Form-based verification actually allows applicationsProgramDefine your own verification screen and credibility verification. When a user enters, a pre-defined image is displayed and a verification element is requested. After the input is completed, the user logic is used to verify the input. If the input passes, the application is entered. Otherwise, the start input screen is returned. Form-based verification usually uses cookies for verification tasks. To enable form-based authentication, set <Authentication mode = "cookie"/> in config. Web.
For example, if form-based authentication is used, the configuration section for rejecting anonymous users is as follows:
<! -- Config. Web->
...
<Configuration>
<Security>
<Authentication mode = "cookie"/>
<Authorization>
<Deny users = "? "/>
</Authorization>
</Security>
</Configuration>
...
In the <authorization> section, the deny ID is used to prohibit a user. Represents anonymous users. "*" represents all users. Of course, after users, you can also follow the specified user to deny the specified user.
In addition, there is a cookie identifier in the configuration section, which specifies the cookie behavior and is more important. The cookie identifier has three attributes:
• Decryptionkey is used to specify the key for encryption and decryption of cookies. If autogenerate is not specified or specified, the key uses the system key generated by crypto API. When autogenerate is specified, the generated key is related to the machine. Therefore, it cannot be used across machines and platforms unless the key is displayed.
• Loginurl verification page. The page to which the user is redirected after authentication fails. It can be local or on another machine.
• Cookie specifies the name of the cookie used to verify the task. Because multiple applications may exist on the same machine and the same application uses one cookie name, the cookie names on the same machine cannot be the same.
For example, the following definitions are available in config. Web:
<! -- Config. Web -->
...
<Security>
<Authentication mode = "cookie">
<Cookie decryptionkey = "autogenerate" loginurl = "login. aspx"
Cookie = ". aspxcookiedemo"/>
</Authentication>
</Security>
...
From this configuration, we can know that the cookie key is generated by the system. When verification fails, the page will jump to login. aspx with the Cook name ". aspxcookiedemo"
In form-based verification, a common object is cookauthentication.
Cookauthentication has four important methods:
• Redirectfromloginpage method, which usually returns the page on which the user starts the request from the user's verification screen after the verification is successful. It has two parameters. The first parameter is the user name to be recorded by the cookie, and the second parameter indicates whether it is recorded in the permanent cookie.
For example:
Cookieauthentication. redirectfromloginpage ("Chen", true)
Indicates that the user "Chen" is recorded in the cookie record on the hard disk, and then jumps to the page on the user's original request.
• Getauthcookie obtains the value of the specified user name from the cookie. Its parameters are the same as those of the redirectfromloginpage method.
For example:
Cookieauthentication. getauthcookie ("Chen", flase)
This indicates that the user name "Chen" is retrieved from the cookie of the current connection.
• Setauthcookie stores the specified user name in the cookie. The parameter is consistent with the getauthcookie method.
For example:
Cookieauthentication. setauthcookie ("Chen", flase)
Indicates that the user "Chen" is recorded in the cookie that exists during the connection process.
• Signout deletes the current user's authentication cookie, which does not care whether the cookie is in the memory or on the hard disk.
The following is a complete example:
Application \ delault. aspx file:
<% @ Import namespace = "system. Web. Security" %>
<HTML>
<Script language = "VB" runat = Server>
Sub page_load (SRC as object, e as eventargs)
Welcome. Text = "hello," + User. Identity. Name
End sub
Sub signout_click (SRC as object, e as eventargs)
Cookieauthentication. signout ()
'Delete cookies
Response. Redirect ("login. aspx ")
'Back to verification Screen
End sub
</SCRIPT>
<Body>
<H3> <font face = "verdana"> cookie authentication </font>
<Form runat = Server>
<H3> <asp: Label id = "welcome" runat = server/>
<Asp: button text = "signout" onclick = "signout_click" runat = server/>
</Form>
</Body>
</Html>
Application \ login. aspx file:
<% @ Import namespace = "system. Web. Security" %>
<HTML>
<Script language = "VB" runat = Server>
Sub login_click (SRC as object, e as eventargs)
If (useremail. value = "test@263.net" or useremail. value = "try@163.net") and userpass. value = "password"
'If the user is a test@263.net or try@163.net and the password is password, it is considered verified
Cookieauthentication. redirectfromloginpage (useremail. Value, persistcookie. Checked)
'Record the cookie and jump to the requested page
Else
MSG. Text = "invalid user or password: Please try again"
End if
End sub
</SCRIPT>
<Body>
<Form runat = Server>
<H3> <font face = "verdana"> logon window </font>
<Table>
<Tr>
<TD> email address: </TD>
<TD> <input id = "useremail" type = "text" runat = server/> </TD>
<TD> <asp: requiredfieldvalidator controltovalidate = "useremail" display = "static" errormessage = "*" runat = server/> </TD>
</Tr>
<Tr>
<TD> password: </TD>
<TD> <input id = "userpass" type = PASSWORD runat = server/> </TD>
<TD> <asp: requiredfieldvalidator controltovalidate = "userpass" display = "static" errormessage = "*" runat = server/> </TD>
</Tr>
<Tr>
<TD> permanent COOKIE: </TD>
<TD> <asp: checkbox id = persistcookie runat = "server"/> </TD>
<TD> </TD>
</Tr>
</Table>
<Asp: button text = "login" onclick = "login_click" runat = server/>
<P>
<Asp: Label id = "MSG" forecolor = "red" font-name = "verdana" font-size = "10" runat = server/>
</Form>
</Body>
</Html>
Config. Web file:
<Configuration>
You can also set the user and password in config. Web. When the user enters the user and password in the Authentication Window, bring it into cookieauthenticationmanager. authenticate to verify whether it is a legal user.
In config. Web, set the user and password to use the credentials ID. It has a passwordformat attribute that determines the Password Storage Method. Passwordformat can be the following values:
• Clear passwords are stored in plain text.
• The sha1 password is stored as sha1.
• The MD5 password is stored in MD5 mode.
For example, in a configuration file,
<! -- Config. Web -->
...
<Configuration>
...
<Security>
<Authentication>
<Credentials passwordformat = "sha1">
<User name = "Li" Password = "gasdfsa9823598asdbad"/>
<User name = "Chen" Password = "zasdfadsfasd23483142"/>
</Credentials>
</Authentication>
</Security>
...
</Configuration>
In this example, we can see that passwordformat in the credentials ID is sha1, so the following user's password is encrypted in The sha1 format. Between <credentials> and </Credentials>, we define two users: "Chen" and "Li". Their passwords are unrecognizable.
4.5.4 authorized users and Roles
URL Authorization controls access to resources. It allows some users and roles to have access to resources, or deny access to resources by some users and roles. It can even determine the HTTP method that can access resources (for example, do not allow get or post ).
For the control of authorized users and roles, Asp.net is implemented through the <authorization> identification segment in config. Web. <Allow> identity indicates that access to resources is allowed, and <deny> identity indicates that access to resources is denied.
They both have two attributes, users and roles, respectively, representing the user and role.
Let's look at an example:
<! -- Config. Web->
...
<Configuration>
<Security>
<Authorization>
<Allow users = "nobody@163.net"/>
<Allow roles = "Admins"/>
<Deny users = "*"/>
</Authorization>
</Security>
</Configuration>
...
It shows the fact that the user "nobody@163.net" and the role admins have the right to access the site and other users will be denied access to the site. That is, the user nobody@163.net and role Admins are authorized users and authorized roles.
Similarly, we can define that multiple users or roles are authorized or prohibited. They are separated by commas.
For example:
...
<Allow users = "Chen, Li, Wang"/>
<Deny roles = "admins, everyone"/>
...
"Chen", "Li", and "Wang" are authorized users, but the roles "Admins" or "everyone" are excluded.
Its effect is the same as that of separate writing. The preceding example can also be written as follows:
...
<Allow users = "Chen"/>
<Allow users = "Li"/>
<Allow users = "Wang"/>
<Deny roles = "Admins"/>
<Deny roles = "everyone"/>
...
In addition, you can determine whether a user's HTTP method can be allowed. The method uses the verb attribute to indicate the HTTP method operation.
For example:
...
<Allow verb = post users = "Chen, Li"/>
<Deny verb = get roles = "everyone"/>
...
Allow the user "Chen" and "Li" to access resources using the POST method, and deny the access to resources using the get method of the role everyone.
symbol "*" and "? "The and identifiers have special meanings ." * "Represents any user ,"? "Represents an anonymous user.
example:
...
indicates that all users except Anonymous Users are allowed to access the site.
as we learned earlier, the application in Asp.net is tree-based, so its configuration file is also hierarchical, this results in that user and Role authorization is not a single result. It depends on the collection of all the results specified in the configuration file along the tree structure, and the closer it is to the configuration of the leaf node, the more effective it is.
for example, access HTTP: www.my.com/myapp/a.aspx
the configuration file config. web in the root directory of http: www.my.com contains the following content:
...
...
the configuration file config. web in the MyApp directory is as follows:
...
...
so what is the set of authorized users? Asp.net first obtains the configuration under the root directory of the site, that is, all users are allowed to access the site, and then Asp.net enters the directory of MyApp to obtain the configuration under it, all users except the user "Chen" are rejected, and the two authorization sets are merged. If there is a conflict between the two, the latter prevails. Therefore, the final authorization set is "Chen", and other users are rejected.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
