Overview of ASP. NET configuration files (2)

Next let's take a look at the <location/> node. We often set this node in the configuration file to authorize URL access. You can add the following configuration in the web. config of an ASP. NET Website (for example, c: \ Inetpub \ wwwroot \ demo \ WEB. config: < Location Path = "Some path" >
< System. Web >
< Authorization >
< Allow Roles = "Secured, Administrators"   />
< Deny Users = "*"   />
</ Authorization >
</ System. Web >
</ Location >

 

The <location/> element is interpreted as a new virtual configuration file. In other words, we can also take out the configuration in the <location/> element and put it in a separate web. config. config. Therefore, you must declare <system. Web> In the <location/> element, and you cannot directly place the <authorization/> element under <location/>.

In websites, you often need to authorize access to many pages, so we can also put those pages in a folder and then put a web. config in the folder. Compared with the former, it is better to use the <location/> element in the root directory of the website for URL Authorization, because all files can be authorized and modified in a file. In addition, if there are many folders for URL Authorization, I think it may be omitted during modification, resulting in running failure.

In <location/>, a path attribute is used to set the file or folder for URL Authorization. In addition, the configuration of the path attribute is flexible. You can set the path value to set URL Authorization for a file, such as Path = "default. aspx ", you can also authorize access to folders, such as" subfolder "(Note: subfolder is a folder in the website), you can also combine the previous two, such as" subfolder/default. aspx "," subfoldera/subfolderb ". if we place a web. config. You can also set authorized access to a website, such as "Default webdite ". Therefore, you can use the path element in <location/> to centrally control the files and folders to be authorized.
 

Let's take a look at the AllowOverride attribute.
Many node elements have this attribute, which can prevent an element of the configuration file at the upper level from being overwritten in the configuration file at the lower level (for the hierarchical relationship of the configuration file, see article 1, from top to bottom: machine. config -- web. config ). For <location/>, If you configure the following in machine. config:

< Location AllowOverride = "False" >
< System. Web >
< Trust Level = "Medium"   />
</ System. Web >
</ Location >

 

 

If you redefine <location/> in the web. config file of your website, an error is returned.

Use of lock-related attributes
It mainly includes lockattributes, lockelements, lockallattributesexcept, and lockallelementsexcept, which can be understood literally.
First, let's take a look at lockattributes. We can define the lockattributes or lockallattributesexcept of an element at a very high level. For example, we can. set the attribute of an element in config so that the web. config cannot override the locked attribute. For example, we know that <membership/> has many attributes: defaultprovider, userisonlinetimewindow, and hashalgorithmtype. Maybe we want allProgramThe provider (providers) is configured with hashalgorithmtype = sha256 hash encryption because of security requirements.

We usually configure this in the web. config of our website:

< Membership Defaultprovider = "Firstproviderdefinition"
Hashalgorithmtype = "Sha1"
Userisonlinetimewindow = "15"   >

 

 

We may think that sha1 encryption is not secure enough. We will configure it in machine. config:

< Membership Hashalgorithmtype = "Sha256" Lockattributes = "Hashalgorithmtype" >

 

In this way, we will no longer be able to modify hashalgorithmtype for our website.
Likewise, we can lock multiple attributes:

<MembershipHashalgorithmtype= "Sha256"Lockattributes= "Hashalgorithmtype; userisonlinetimewindow; defaultprovider">

 

 

Similarly, the usage of lockallattributesexcept is not described in detail, for example:

< Membership Hashalgorithmtype = "Sha256" Lockallattributesexcept = "Userisonlinetimewindow"   >

 

If the configuration in machine. config is as follows: <membership... lockattributes = "*"/>, you cannot override any attributes of membership on each website.

Next let's take a look at the locking element.
We also use the <membership/> node as an example. In <membership/>, we can add many node elements, such as <providers/>, <Add/>, <remove/>, <clear/>, we can also. config locks an element, such as <membership lockelements = "providers">. Therefore, any attempt to change <providers/> on the website we develop will fail.
Similarly, the usage of lockallelementsexcept is the same as that of lockallattributesexcept. In addition, we can lock all elements as follows:

< Membership >
< Providers Lockelements = "*" >
</ Providers >
</ Membership >

 

In addition, the locking elements and attributes above can be used together. For example:

 

< Membership Lockelements = "Providers" Lockattributes = "Defaultprovider, hashalgorithmtype" >