Introduction:
One of the advantages of grouping individual pages together into an application
is that values can be set for all these pages at once by setting the properties
of the application. The settings of values for the properties of an application
that will control the application at runtime is known as configuring the ASP.Net
application.
In ASP.Net, all that needs to be done to configure an application is to create a
Configuration file called 'Web.config' and place it in the root directory of the
application. The settings that are provided in this file are applied throughout
the application, including its sub-directories. This 'Web.config' is an XML
based file.
Different Configuration Settings:
The different configuration settings for an ASP.Net application that can be
defined in the 'Web.config' file are:
A. <appSettings>
The Application settings section is enclosed between the <appSettings> and </appSettings>
tags. These settings allow the user to set the application configuration
details. Application settings enable the user to store and retrieve information
as key-value pairs. It simply populates a Hash Table, which can be easily
accessed through ASP.Net pages. It is also possible to store SQL queries, as
show in below Code Snippet 1:
Code Snippet 1:
<configuration>
<appSettings>
<add
key="MySQLQuery"
value="select *
from MySQLTable"/>
</appSettings>
</configuration>
The key value pair, as can be seen from Code Snippet 1, is enclosed within the <appSettings>
tag. The configuration settings stored in the config files can be read back in
an ASP.Net page using the command show in Code Snippet 2.
Code Snippet 2:
. . .
String GetQuery = ConfigurationSettings.AppSettings["MySQLQuery"];
. . .
B. <Pages>
The <pages> configuration setting allows the developer to control some of the
default behaviors for all the ASP.Net Pages in the application or machine. These
behaviors include options such as whether the output should be buffered before
sending, and whether Session state is enabled for pages within the application.
The properties that can be set at the page level are listed in below table with
their description:
Property |
Description |
Default Values |
Buffer |
Sets whether the
response to a client is sent directly or is first buffered on the server
and then sent. |
True |
enableViewState |
Sets whether
ViewState is to be enabled or disabled. |
True |
Code Snippet 3 shows how the pages
configuration settings can be implemented in a 'Web.config' file.
Code Snippet 3:
<configuration>
<system.web>
<pages
buffer="true"
enableViewState="false"/>
</system.web>
</configuration>
C. <SessionState>
SessionState, like many other ASP.Net services, can be configured through the
'Web.config' file. The below table lists the various attributes of sessionState
along with their descriptions.
Property |
Description |
Default Value |
mode |
Specifies whether
to store the session state. The various options for this attributes are
:
Off
- this indicated that session is not enabled
InProc -
this indicates that session state is
stored locally
StateServer -
this indicated that session
state is stored on a remote server
SqlServer -
this indicates that session
state is stored on a SQL Server |
inProc |
cookieless |
Specifies whether
session without cookies should be used to identify client sessions. |
false |
timeout |
Specifies the time
in minutes for which a session can be idle before it is abandoned. |
20 minutes |
stateConnectionString |
Specifies the
server name and port where the session is stored remotely. |
|
sqlConnectionString |
Specifies the
connection string for the SQL Server. |
|
Code Snippet 4 shows the SessionState settings
in a 'Web.config' file
Code Snippet 4:
<configuration>
<System.web>
<SessionState
mode="inproc"
cookieless="false"
timeout="20"/>
</System.web>
</configuration>
We have seen 3 configuration settings which are <appSettings>, <Pages> & <SessionState>
for an ASP.Net application in PART 1.
D. <customErrors>
ASP.Net provides the flexibility to write custom error pages and redirect the
browser (client) to these error pages when any specific error occurs. For
example, if a resource (file, image, audio file) is not found on the server,
instead of displaying to the user a "404 Not Found" error message, the error can
be trapped and the browser can be re-directed to a pre-designed page. The error
pages to be displayed can be designed to give a more polite and user - friendly
explanation of the error and if cause. The syntax for this configuration setting
is shown in Code Snippet 5.
Code Snippet 5:
<customErrors
defaultRedirect="url"
mode="On|Off|RemoteOnly>
<error
statusCode="statuscode"
redirect="url"/>
</customErrors>
Where,
defaultRedirect attribute specifies the default page where the client will be
redirect if an unhandled error occurs.
Mode specifies whether the customErrors option is turned on. Mode will be set to
RemoteOnly if the custom error pages are to be displayed only to the remote
clients, and not to people working from the local machine.
customErrors tag allows a sub-tag <error> to be defined, which takes two
attributes, namely statusCode & redirect.
The statusCode attribute is used to trap the error code and the redirect
attribute specifies to which page the response should be redirected on the
occurrence of the specified error.
Code snippet 6 shows a sample for the customError Settings.
Code Snippet 6:
<configuration>
<system.web>
<customErrors
defaultRedirect="http://localhost/Appdir/AllErrors.aspx"
mode="RemoteOnly">
<error
statusCode="404"
redirect="http://localhost/Appdir/ErrorNo404.aspx"/>
</customErrors>
</system.web>
</configuration>
In above code snippet, the Web.config file redirects the page request to a page
called 'ErrorNo404.aspx', in case the 404 error occurs. In case of any other
error, the request is redirected to the 'AllErrors.aspx' page.
E. <Authentication>
Some web sties changes for their services. For example, consider email sites.
Though many are available for free, for some premium value addition services,
most of the sites charges a fee. Entry into the paid section is granted to the
user only if the user has a valid user name and password. The process of
validating the username and password is known as Authentication. In the days
prior to ASP.NET, huge amounts of code needed to be written for the
authentication routines. However, with the advent of ASP.Net, it has been
reduced to a few lines of code. The settings can be specified in the
'web.config' file itself. The syntax for doing the same is illustrated in below
code snippet 7.
Code Snippet 7:
<configuration>
<system.web>
<authentication
mode="Windows|Forms|Passport|None">
<forms
name="name"
loginUrl="url"
Protection="All|None|Encryption"
timeout="xx"
path="/">
<credentials
passwordFormat="Clear|SHA1|MD5">
<user
name="username"
password="password"/>
</credentials>
</forms>
<passport
redirectUrl="internal"/>
</authentication>
</system.web>
</configuration>
In Code Snippet 7, the mode specifies the type of authentication that is to be
performed. The options could be one of the four as described in below table.
Authentication
Type |
Description |
Windows |
Specifies windows
authentication as the default authentication mode. This mode will be
used in case of any form internet information service (IIS)
authentication. |
Forms |
Specifies ASP.NET
forms based authentication as the default authentication mode. |
Passport |
Specifies
Microsoft Passport authentication as the default authentication mode. |
None |
Specifies no
authentication, Only anonymous users are expected or application can
handle events to provide their own authenticatio |