C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

A configuration section handler must be declared for each configuration Note section in the file.

An example of using the <configSections> section is as follows:

<configSections>

<httpModules>

<section name="System.Web.Caching.OutputCacheModule" />

<section name="System.Web.SessionState.SessionStateModule" />

</httpModules>

</configSections>

The <httpModules> section has a configuration handler that is set to System.Web.Caching.OutputCacheModule, and the <sessionState> section has a configuration handler that is set to System.Web.SessionState.SessionStateModule classes.

<appSettings> section

The <appSettings> section of the Web.config file provides a way to define custom application settings for an application. The section can have multiple <add> subelements. The syntax is as follows:

<appSettings>

<add Key="[key]" Value="[value]"/>

</appSettings>

The <add> subelement supports two attributes:

§Key: Specifies the key value in an appsettings hashtable

§Value: Specifies the value in an appsettings hashtable

An example is as follows:

<appSettings>

<add Key="dsn"

Value="localhost;uid=user1;pwd=password"/>

</appSettings>

The Key value is set to dsn, and the Value is set to the name of a server, user ID, and password.

<browserCaps> section

The <browserCaps> section of the Web.config file enables you to specify the configuration settings for the browser capabilities component.

Note The HttpBrowserCapabilities class contains all the browser properties. These properties can be retrieved and set in this section.

The syntax is as follows:

<browserCaps>

<result type="System.Web.HttpBrowserCapabilities" />

<use var="Environment Variable" />

browser="type"

version=browser version

majorver=0

minorver=0

frames=false/true

tables=false/true

<filter>

<case match="Name of operating systems to match">

platform="Current OS"

</case>

. . .

</filter>

</browserCaps>

In this syntax:

§The <result> tag specifies the class that contains all the browser capabilities.

§The <use> tag defines the environment variable, such as HTTP_USER_AGENT, which is to be matched to determine the browser being used.

§The <filter> tag specifies the operating system on which the browser is running. This tag can be used to filter the browsers that are running on specific platforms.

An example is as follows:

<browserCaps>

<result type="System.Web.HttpBrowserCapabilities" />

<use var="HTTP_USER_AGENT" >

browser="Unknown"

version=0.0

majorver=0

minorver=0

frames=false

tables=false />

<filter>

<case match="Windows 95|Win95">

platform=Win95

</case>

<case match="Windows NT|WinNT">

platform=WinNT

</case>

</filter>

</browserCaps>

This sets the result type to BrowserCapabilities and also sets certain environmental variables.

<compilation> section

The <compilation> section contains all the compilation settings used by ASP.NET. Some of the settings involve setting a default language and debug option for the application setting. The section also provides support for the <compilers>, <assemblies> , and <namespaces> subelements. The syntax is as follows:

<compilation debug="true/false">

<compilers defaultLanguage="[Lang]">

<compiler

language="[Lang]"

extension="[ Ext]"

type="Type[,assemblyName]"/>

</compiler>

<assemblies>

<add assembly="[Assembly] " />

<remove assembly="[Assembly]" />

<clear />

</assemblies>

<namespaces>

<add namespace="[namespace]"/>

<remove namespace="[namespace]"/>

<clear/>

</namespaces>

</compilation>

The <compilation> element supports the debug attribute, which can take either a True or False value, and indicates whether compilation should be retail (False) or debug (True) binaries. The default value is False. If the value is set to True, the temporary source file is not immediately deleted from the codegen directory. This is helpful for debugging compilation and parser errors.

This syntax uses three subelements, <compilers>, <assemblies>, and <namespaces>. These elements are explained in the following sections.

<compilers> subelement

The <compilers> section can contain multiple <compiler> subelements, which are used to create a new compiler definition. The <compiler> subelement has three attributes:

§Language: Provides a list of languages, separated by semicolons, used in dynamic compilation files. For example, C#; VB; JScript; and PERL.

§Extension: Provides a list of file name extensions, separated by semicolons, used for dynamic code behind files. For example, .pl; .cls; and .js.

§Type: Indicates the .NET Framework class, which implements the ICompiler interface and that should be used to compile all resources that use either the specified language or the file extension.

<assemblies> subelement

The subelement <assemblies> is used to add or remove assembly references that need to be used during the compilation of a dynamic resource. These assemblies are also loaded at run time. Therefore, this element allows both early and late binding. This element has three attributes:

§Add: Used to add an assembly reference to be used during the compilation of a dynamic resource. ASP.NET will automatically link this assembly when compiling each code module. The value specified is an assembly name and not a DLL path. ASP.NET will first perform a lookup on the supplied assembly name to find the physical location of the DLL. A developer can optionally specify * to add every assembly within an application's private assembly cache, which is located in the bin subdirectory of an application, or in the Microsoft .NET Framework install directory (%windir%\ComPlus\Version\).

§The defaultRedirect attribute is an optional attribute of the section and is used to indicate the default URL to which the client browser should be redirected if an error occurs.

§The mode attribute is used to specify if the status of the custom errors is enabled, disabled, or only shown to remote machines. This attribute takes one of three values: On, Off, RemoteOnly. On indicates that the custom errors are enabled. Off indicates that the custom errors are

disabled. RemoteOnly indicates that the custom errors will be shown only to remote clients.

The <customErrors> section supports multiple <error> subelements that are used to define custom errors. Each <error> subelement supports two attributes:

§Statuscode: Specifies an error status code that causes a browser to be directed to an error page, which is not the default error page.

§Type: The URL to which the browser should be redirected in the event an error occurs.

An example is as follows:

<customErrors defaultRedirect="customerror.htm"

mode="On">

<error statusCode="500"

redirect="CustomInternalError.htm"/>

</customErrors>

The custom error file for the application is set to Customerror.htm, the error code is 500, and the error-redirection file is set to CustomInternalError.htm.

<globalization> section

The <globalization> section is used to configure the globalization settings of the application. The syntax is as follows:

<globalization

requestEncoding="[any valid encoding string]"

responseEncoding="[any valid encoding string]"

fileEncoding="[any valid encoding string]"

culture="[any valid culture string]"

uiCulture="[any valid culture string]"

/>

The <globalization> element supports the following attributes:

§requestEncoding: Used to check for the encoding of each incoming request. The default value for this attribute set in the machine-level Web.config file is iso-8859-1.

§responseEncoding: Used to check for the content encoding of responses. The default value for this attribute as set in the machine-level Web.config file is: iso-8859-1.

§fileEncoding: Used to check for default encoding forASPX, ASMX, and ASAX file parsing.

§culture: Used to check for the default culture used to process incoming Web requests. Valid culture strings are specified in the System.Globalization.CultureInfo class.

§uiCulture: Used to check for the default cultures that are used to lookup for resources that need to be used for the current page.

An example is as follows:

<globalization

fileEncoding="utf-8"

requestEncoding="utf-8"

responseEncoding="utf-8"

/>

This section sets the fileEncoding, requestEncoding, and responseEncoding attributes to "utf-8".

<httpHandlers> section

The <httpHandlers> section maps the incoming URL requests to the classes that implement IHttpHandler or IHTTPHandler interfaces. The syntax is as follows:

<httpHandlers>

<add verb="[verb list]"

path="[path/wildcard]"

type="Type[,assemblyName]" />

<remove verb="[verb list]"

path="[path/wildcard]" />

<clear />

</httpHandlers>

The child elements supported by this section are described as follows:

§Add: Used to add a verb/path mapping to an IHttpHandler or

IHttpHandlerFactory interface. The following are the attributes used:

oVerb: Specifies the method used for receiving the data. The verb list can be either a comma-separated list of HTTP verbs, such as GET, PUT, or POST, or a start-script

mapping, such as *.

oPath: The Path attribute specifies a path from where the incoming requests are generated. The path attribute can contain either a single URL path or a simple wildcard, such as *.aspx.

oType: Composed of an assembly and a class combination — the two values are separated by a # character. The assembly DLL is always resolved first against an application's private "bin" directory, and then against the system assembly cache.

§Remove: Used to remove a verb/path mapping to an IHTTPHandler or an IHTTPHandlerFactory interface. The Remove directive should match the verb/path combination of a previous add directive in order to remove an entry. The attributes in this element do not support the use of wildcards.

§Clear: Used for removing all the IHttpHandlerFactory mappings that are currently configured or inherited by a particular Web.config file.

The following is an example:

<httpHandlers>

<add verb="*" path="FirstApp.Mack" Type="FirstApp.Mack,

FirstApp" />

<add verb="*" path="FirstApp.Gaze" Type=" FirstApp.Gaze,

FirstApp" />

</httpHandlers>

This section sets the verb to use all the methods along with the path and type of files.

<httpModules> section

The <httpModules> section is used for adding, removing, or clearing HTTP modules in an application. The syntax is as follows:

<httpModules>

<Add Type="Type [,assemblyName]" name="module name"/>

<Remove Type="Type [,assemblyName]" name="module name"/>

<Clear />

</httpModules>

The section can be configured using the three following subtag directives:

§Add: Used to add HttpModule classes to an application. This element takes two attributes: Type and Name. The Type attribute is composed of an assembly and class combination. The Name attribute specifies the name used in the application to refer to this assembly. If the Name attribute is omitted, the assembly name is used to refer to the module.

§Remove: Used to remove an HttpModule class from an application. This subtag also takes two attributes: Type and Name.

§Clear: Used to remove all the HttpModules mappings that are currently configured or inherited by a particular Web.config file from the application.

An example is as follows:

<httpModules>

<add Type="System.Web.State.CookielessSessionModule" />

<add Type="System.Web.OutputCacheModule" />

<add Type="System.Web.State.SessionStateModule" />

<add Type="FirstClass, FirstAssembly" />

</httpModules>

This sets the types to three different values of the assembly class combination.

Security settings in Web.config files

ASP.NET enables you to manage the entire security configuration from the Web.config file. The security configuration is implemented by using three sections:

<authentication>, <authorization>, and <identity>. The syntax for the three sections is as follows:

<configuration>

<system.web>

<authentication mode="[Windows/Forms/Passport]"> <Forms name="[name]" loginurl="[url]" protection= "All/None/Encryption/Validation" timeout="30" path="/">

<credentials passwordformat="[Clear/ SHA1/ MD5]"> <user name="[UserName]" password="[password]"/> </credentials>

</forms>

<passport redirectUrl="url"/>

</authentication>

<authorization>

<allow users="[comma separated list of users]"

roles="[comma separated list of roles]"/>

<deny users="[comma separated list of users]"

roles="[comma separated list of roles]"/>

</authorization>

<identity>

<impersonation enable="[true/false]"/>

</identity>

</system.web>

</configuration>

The three security sections have elements for which the values are set by overriding the section of the machine-level configuration file with a similar section in an application configuration file placed in the application root. All subdirectories automatically inherit the settings defined. However, subdirectories can have their own configuration files that override their parent directory's settings.

The <identity> section is used to enable or disable impersonation. Impersonation is the ability of a thread to execute in a security context that is different from the context of the process that owns the thread. The other two sections are described next in more detail.

<authentication> section

This element takes an attribute "mode" that controls the default authentication mode for an application. This attribute can be set to one of the following values:

§ Windows: Uses IIS authentication, which can be Basic, Digest, or Windows (NTLM) authentication, or a combination of these.

§Passport: Uses the Passport cookie authentication. To set this value, the Passport SDK must be installed and the user must subscribe to the Passport service.

§Forms: Uses the ASP.NET forms-based cookie authentication.

The <authentication> section also supports one subelement <forms>, which defines cookie authentication settings. This element supports three attributes, which are described as follows:

§ Name: Specifies the name of the HTTP cookie to be used for the authentication ticket. By default, the value is set to ASPXAUTH.

§loginUrl: Defines the URL to which the request is redirected if it doesn't contain a valid authentication ticket.

§Protection: Specifies the protection technique applied to

safeguard the cookie data. The following are the possible values for this attribute:

o All: The cookie is protected by encrypting the cookie data as well as by validating the contents of the cookie using a message authentication code.

oNone: The cookie is not protected. This value is not recommended due to security

concerns. However, it can be used for the sites that do not use cookies for security, but only for personalization of information to users.

o Encryption: The contents of the cookie are encrypted by using DES encryption.

oValidation: Defines the URL to which the request is redirected, if it doesn't contain a valid authentication ticket.

§TimeOut: Specifies the time after which the cookie expires. If

a user wishes to access the site after the timeout has expired, the user will have to reauthenticate and get a new cookie.

§Path: Specifies the path of the cookie issued by ASP.NET on behalf of the Web application represented by the Web.config file.

§Decryptionkey: Specifies a key to be used for decrypting the authentication tickets. If login and authentication are distributed across multiple machines, they all need to share

the same key. The key is stored in cleartext.

The <forms> subtag optionally allows users to define name/password credentials within the <credentials> subtag. Alternatively, developers can implement their own custom password scheme wherein validation occurs from external stores, such as databases. The <credentials> child element contains an attribute, passwordformat, which defines the encryption format used to store passwords. In addition to the passwordformat attribute, the element supports multiple <user> subelements. A <user> subelement has the following attributes:

§name: Indicates the user login name

§password: Indicates the user password

<authorization> section

Authorization for an ASP.NET application can be implemented by using the <authorization> subelement. This element controls client access to the ASP.NET resources at a given URL. The settings specified in an <authorization> element are inherited by subdirectories hierarchically.

The <authorization> element is configured by using two subelements, <allow> and <deny>, which are interpreted and processed in top-down sequential order. The <allow> element enables administrators to explicitly identify a class of users to whom access should be granted. The <deny> element enables administrators to explicitly identify a class of users to which access is denied. The <allow> and <deny> elements take the following two attributes:

§Users: Contains a comma-separated list of usernames that should be granted access. The ? character allows or denies access to anonymous users, and the * character allows or denies access to all users.

§Roles: Contains a comma-separated list of roles that should

be granted or revoked access.

While the application is running, the authorization module iterates through the <allow> and <deny> elements to search for the first access rule that is applied for a particular user. The element decides to grant or reject access to a URL resource depending on whether the first access rule satisfied is an <allow> or a <deny> rule. By default, the access is rejected if no rule is found. The following is an example:

<configuration>

<system.web>

<authentication mode="Cookie">

<forms name="401kApp" loginUrl="/Firstlogin.aspx"

protection="All">

<credentials passwordformat="SHA1">

<user name="Marie" password="GAF97FSA3223NTT"/>

<user name="Caste" password="DF^$3GFDX443BSD99"/>

<user name="RockMen" password="IDCJMWAFSLKSTGDLS##"/>

</credentials>

</forms>

</authentication>

<authorization>

<allow roles="Admins", "Managers" />

<allow users=" Caste, "John" />

<deny users="Jane", " RockMen " />

</authorization>

<identity>

<impersonation enable="false"/>

</identity>

</ system.web>

</configuration>

This uses all the attributes to set the security settings for the application.

<processModel> section

The <processModel> section is responsible for configuring the ASP.NET process model settings on an IIS Web server. The process model settings are used for defining how the threads within a process should work.

Note The <processModel> section can appear only in the machine-level Web.config file.

The syntax is as follows:

<processModel

enable="[true/false]"

timeout="[mins]"

idleTimeout="[mins]"

shutdownTimeout="[secs]"

requestLimit="[num]"

requestQueueLimit="[num]"

memoryLimit="[percent]"

cpuMask="[num]"

webGarden="[true/false]"

userName="username"

password="password"

/>

The <processModel> element supports the following attributes:

§enable: Specifies a value that indicates whether or not the process model is enabled.