When I learned asp.net, I found that Web.config was useful, I found some information, gathered here for those needed. All .NET applications are saved in an XML-based configuration file. The web application uses the web.config file located in the application root directory, which is related to the information included with the web.config of the ASP.NET application and most of its applications. With Web.config, you can define settings such as custom 404 error pages, (identity) authentication and authorization; if you are allowed, you can also build an option for the ASP.NET web page. Web.config is the tag of
...
The above code adds a CONNSTRING APPLICATION-WIDE setting, providing the value of the data connection string by the Connection String. Now, in most ASP.NET web pages of this site, you can read the value of this parameter with the following statement:
String Connstr = configurationSettings.appsettings ("Connstring") If you are creating a large ASP.NET application, a wise decision is to define a large number of websites global management, and the adjustment attribute is defined as the Application-Wide parameter. So far, you can use the AppSettings tag like it just now. There is a problem here. If someone wants to integrate your program, if there is already the same configuration as the name, he will not have to modify the large-scale modification, so that the conflict is not created. In this case, don't happen, you will see what you want to put the site.
To avoid this confusion, you can set the application's setup "packet" as a unique tag in the web.config file. That is to say, you can create a tag called
Type = "System.configuration.nameValueFileerationHandler, System, Version = 1.0.3300.0, Culture = Neutral, PublicKeyToken = B77A5C561934E089 "/> ... note: The Type attribute values in the mark must be written in the same row, and the wrap here is clearer. This mark indicates that a custom named myAppSettingS will be added. From now on, in order to add Application-Wide parameters, we can add a TYPE = "System.configuration.nameValueFileeSectionHandler, System, Version = 1.0.3300.0, Culture = Neutral, PublicKeyToken = B77A5C561934E089 "/> ... Finally, in order to read this custom value in the ASP.NET web page, we use the following syntax: ConfigurationSettings.getConfig ("ConnString") More general practices are: replace myAppSettings to select the name used to store custom setting tags; simultaneously replace Connstring in Custom Settings tags, you want to read the parameter name. In this way, the conflict mentioned above can be effectively solved, of course, special, special circumstances exceptions. In the web.config file, Windows verifies the user, such as an Active Directory, via the Windows system account. Windows verification is the safest verification form, which is very simple for programmers, because the entire process is processed by the operating system. However, each user of the website requires a system of accounts, so this mode will be restricted in an intranet application. Passport verifies that the passport is used to verify the user, it is the second secure verification method. Its best use of martial arts is a large, active Internet e-commerce application, which verifies the user's service usage fee. This mode is the authentication method selected by .NET. Forms Verification is the lowest security verification method, as you must have your application yourself to process the verification process. However, this is the most likely mode that is used on your internet application, as it needs to be minimal. An example of using Forms authentication is as follows: The file directory is: bin admin -index.aspx - test.aspx - * .Asspx - Web.config // Admin File under Web.config Login.aspx Web.config Login.aspx Web.config Rootted Web.config Index.aspx (-) Important methods of formsauthentication and attributes FormScookiename Returns the configured cookie name for the current application. GetAuthCookie creates authentication cookies for a given username. This will not set the cookie to a part of the response, so the application has more control permissions on how the cookie is emitted. Authenticate gives the credentials provided, attempts to verify the credentials based on the credentials included in the configured credential storage area. GetirectURL returns a redirect URL that causes the original request to redirect to the login page. HashPasswordforstoringInfigfile gives a password and string that identifies the hash type, which generates a hash secret code that is suitable for stored in the configuration file. RedirectFromLoginPage redirects the user of the verified identity back to the original request URL. {========= Remarks the RedirectFromLoginPage method to redirect to the returned URL key specified in the query string. For example, in URL http://www.contoso.com/login.aspx?returnURL =caller.aspx, Caller.aspx is the Return URL redirected to RedirectFromLoginPage. If the return button does not exist, RedirectFromLogInPage will redirect to Default.aspx. =========} SetAuthCookie Create a collection of authentication tickets and attach it to the Cookie's outgoing response. It does not perform redirection. Signout Removes the authentication ticket. (2) Let's completely understand how the page is verified once again explain the purpose of our verification: Admin Folder is the "area" of the administrator for background management, only after logging in to login through Login.aspx In order to access all the pages in the Admin folder, we must verify that the user is an administrator by filling in the login.aspx form. (1) Suppose we set a connection Administrator login , administrators can pass this connection, access login.aspx to fill in the form. Here there is a wonderful thinking of thinking, we are used to this "administrator landing" connection to Login .aspx, actually here, we are wrong, should "direct" connect to the Admin folder (or any page inside), someone asking: "This is not ordinary visitors can also connect directly to Admin. ? ", Right! This is based on the wonderful place for form verification. Don't worry about this problem, look at our 2 web.config! Take a look at the web.config in the admin fold. There is a The root directory web.config sets the verification mode, as well as the corresponding processing. = Server /> Account = Server> Password = Server /> Whether to remember password, permanently login Handling event 1 (when the user clicks the login button) Void BtnloginClick (Object Sender, Eventargs E) {IF (User Validation) // This can be placed on the bin directory to verify the user, return a BOOL. {Formsauthentication.RedirectFromLoginPage (username.text, mycheckbox.checked);} 1. Formsauthentication.redirectFromLoginPage (username.text, mycheckbox.checked); -> Set a verification cookie indicating that the user has passed the verification .-> Return to the page you just request (admin / index.aspx); 2, this sentence is equivalent to these two sentences: FormsAuthentication.SetAuthCookie (UserName.Text, mycheckbox.Checked); Response.Redirect (FormsAuthentication.GetRedirectUrl (UserName.Text, mycheckbox.Checked); 3, if mycheckboxt control is already selected, then, write Enter cookie, save 50 years, of course, we can change this time: handling event 1 (when the user clicks the login button) Void BtnloginClick (Object Sender, Eventargs E) {If (user authentication) // This file can be placed in their dll bin directory to authenticate the user, a return bool {HttpCookie authenticationCookie = FormsAuthentication.GetAuthcookie (UserName.Text, mycheckbox.Checked);. AuthenticationCookie.Expires = DateTime .Now.adddays (3); // 3 days response.cookies.add (automationCookie); response.redirect (formsauthentication.getredirectURL (username.text, mycheckbox.checked);} 4, there is a bug, I don't know why, let's: handle event 1 (when the user clicks the login button) Void BtnloginClick (Object Sender, Eventargs E) {IF (User Validation) // This point can be placed on the bin directory to verify the user, return a BOOL. {Formsauthentication.RedirectFromLoginPage (username.text, mycheckbox.checked); response.Redirect ("http: / / www.quickrespondresponser.com ");}} What will it? According to reason, I should execute formsauthentication.RedirectFromLoginPage (UserName.Text, MyCheckBox.checked); then jump to the request page admin / index.aspx. However, during the actual test process, the discovery page executed response.redirect ( "http://www.quickrespondresponser.com"); 5, our link should not involve direct connection to login.aspx, why? Suppose we log in directly to login.asxp, then this URL does not have a parameter returnurl, but the default is Default.aspx (or index.axp ....), when the administrator passes the verification, the page is not directly jumping to the default page of the root directory Index.aspx. (If you are directly connected, it is also possible, using the above BUG Solve) Logout Verification: Formsauthentication.signout (); in fact, the above scheme is not a safe solution. It is just very practical, simple, but also safe verification solution.
