لطفا منتظر باشید ...
Publisher8.2 Modifying Configuration Settings
The most important part of
configuration for the web developer is, of course, understanding how
to modify the configuration files to achieve the desired ends.
Unfortunately, in the first release of the .NET Framework and Visual
Studio .NET, there aren't any rich GUI tools for
editing configuration files (which sounds like a great third-party
opportunity). As a result, editing configuration files is not
terribly straightforward. The next several examples illustrate the
basic techniques for editing web.config files.Remember that ASP.NET configuration files follow XML syntax rules,
including case-sensitivity of element and attribute names. Element
and attribute names in ASP.NET configuration files typically use
camel casing, in which the first letter of the initial word is
lowercase and the first letter of each subsequent word is uppercase.Also note that some (but not all) attribute
values are case-sensitive. While this
case-sensitivity is specific to the ASP.NET implementation rather
than to XML, it's still a good idea to follow the
case used in the examples when modifying configuration files.
8.2.1 Modifying Trace Settings
Tracing is a nifty feature of
ASP.NET that allows recording and viewing of a host of valuable
information about page requests. Like the other configuration
elements considered in this chapter, the
<trace> element appears in
machine.config to set machine-wide default
values:
<!--
trace Attributes:
enabled="[true|false]" - Enable application tracing
localOnly="[true|false]" - View trace results from localhost only
pageOutput="[true|false]" - Display trace ouput on individual pages
requestLimit="[number]" - Number of trace results available in
trace.axd
traceMode="[SortByTime|SortByCategory]" - Sorts trace result
displays based on Time or Category
-->
<trace enabled="false"
localOnly="true"
pageOutput="false"
requestLimit="10"
traceMode="SortByTime"/>
The settings in machine.config turn tracing off
by default, which is a good thing. Since tracing carries performance
overhead, you should enable it only when you are actually using
itusually during development or troubleshooting of an ASP.NET
application. You should rarely enable tracing on a deployed
production application, both for performance reasons and also to
avoid the possibility of trace information being viewed by site
visitors. See Chapter 10 for a more detailed
discussion of application tracing. Example 8-1 shows
the <trace> element modified to enable
tracing for an application, with trace output being displayed on each
page.
Example 8-1. Enabling tracing
<configuration>
<system.web>
<trace enabled="true"
pageOutput="true"/>
</system.web>
</configuration>
You can enable tracing by setting the enabled
attribute to True and direct the trace output to
the page by setting the pageOutput attribute to
True. The attributes shown in Example 8-1 override the settings in
machine.config (and any parent
web.config file that contains a
<trace> element), while the
remaining attributes should retain their default values as set in
machine.config .
8.2.2 Changing the Authentication Mode
Modifying the
<authentication> element of
web.config
should give you a deeper look at how configuration files work. The
<authentication> element is included in the
machine.config
file with the following default settings:
<!--
authentication Attributes:
mode="[Windows|Forms|Passport|None]"
-->
<authentication mode="Windows">
<!--
forms Attributes:
name="[cookie name]" - Name of the cookie used for Forms
Authentication
loginUrl="[url]" - Url to redirect client to for Authentication
protection="[All|None|Encryption|Validation]" - Protection mode
for data in cookie
timeout="[seconds]" - Duration of time for cookie to be valid
(reset on each request)
path="/" - Sets the path for the cookie
-->
<forms name=".ASPXAUTH" loginUrl="login.aspx" protection="All"
timeout="30" path="/">
<!--
credentials Attributes:
passwordFormat="[Clear|SHA1|MD5]" - format of user password
value stored in <user>
-->
<credentials passwordFormat="SHA1">
<!-- <user name="UserName" password="password"/> -->
</credentials>
</forms>
<!--
passport Attributes:
redirectUrl=["url"] - Specifies the page to redirect to, if the
page requires authentication, and the user has not signed on
with passport
-->
<passport redirectUrl="internal"/>
</authentication>
These configuration settings give the machine-wide defaults for
authentication in ASP.NET applications. Windows authentication is
enabled by default. Note that for Windows authentication to function
properly, some form of IIS authentication other than Anonymous must
be enabled. The machine.config settings also
specify defaults for the attributes of the
<forms> element, which is used in
Forms authentication, and for the
<passport> element.Notice that the formatting of the configuration settings denotes the
parent/child relationships of the elements. Both the
<forms> and
<passport> elements are children of the
<authentication> element, while the
<credentials> element is the child of
the <forms> element. The
<user> element (commented out in
the preceding code) is in turn the child of the
<credentials> element.You would see the <forms> element specified
only in machine.config when the mode attribute
of the <authentication> element is set to
Windows, a setting that does not require any child
elements. The reason for this is that these settings are used as
defaults for various authentication methods. Supplying values for the
attributes of the <forms> element at the
machine level provides defaults that are inherited by any application
using Forms authentication automatically, while any attribute values
for the <forms> element contained in
web.config files for specific applications
override these settings.Example 8-2 shows an
<authentication>
element for an application that uses Windows authentication. The
<authorization> element is also shown. In
this case, this element denies access to anonymous users, which
forces authentication, if it has not already occurred.
Example 8-2. Windows authentication settings
<configuration>
<system.web>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
<configuration>
Consider an application in which you want to use Forms authentication
(discussed further in Chapter 9) to enable
authentication against your own custom credential store. In this
case, you would use an authentication element, such as that shown in
Example 8-3, along with its child
<forms> element, and the
<authorization> element shown in Example 8-2. Note that the
<forms> element is required only if
you want to override the settings specified in
machine.config . Example 8-3
specifies a different login page (myLogin.aspx )
to which unauthenticated users are redirected.
Example 8-3. Forms authentication settings
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="myLogin.aspx"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
<configuration>
8.2.3 Configuring Out-of-Process Session State
The <sessionState> configuration element in
machine.config sets the following machine-wide
defaults:
<!-- sessionState Attributes:
mode="[Off|InProc|StateServer|SQLServer]"
stateConnectionString="tcpip=server:port"
stateNetworkTimeout="timeout for network operations with State Server,
in seconds"
sqlConnectionString="valid System.Data.SqlClient.SqlConnection string,
minus Initial Catalog"
cookieless="[true|false]"
timeout="timeout in minutes"
-->
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
stateNetworkTimeout="10"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"/>
Unlike the <authentication> element, the
<sessionState> element has no children, only
attributes. Like the <authentication>
element, the usage of the <sessionState>
element in machine.config contains a combination
of attributes not normally seen in practice, since the purpose of the
attributes is to set machine-wide defaults. For example, the default
mode of in-process session state (InProc) requires no additional
attributes to function. In fact, if you want to use InProc, you do
not need to add a <sessionState> element to
your web.config file at all. Examples Example 8-4 and Example 8-5 show the
appropriate settings for the <sessionState>
element for out-of-process session state using the ASP.NET state
service and SQL Server session state, respectively.
Example 8-4. Out-of-process state with state service
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=StateServerName:42424"
stateNetworkTimeout="30" />
</system.web>
<configuration>
Example 8-4 sets the mode
attribute to StateServer, which uses the ASP.NET
state NT service installed with ASP.NET to store session state
settings for multiple machines. This setting requires the
stateConnectionString attribute; since the default
setting of 127.0.0.1 (the local machine loopback address) is not
terribly useful for sharing state information across multiple
machines, you need to replace it with the name of the machine that is
responsible for maintaining this information
(StateServerName in the example).In out-of-process session state scenarios, a single machine is
designated to maintain session values for multiple ASP.NET servers.
Therefore, each server using the shared session information should be
configured to point to the same state server. To compensate for
potential network latency issues, the example changes the default
stateNetworkTimeout value of 10 seconds to 30
seconds. Note that inherent in this decision is a tradeoff between
avoiding timeouts and potentially poorer application performance.
|
Example 8-5. Out-of-process state with SQL Server
<configuration>
<system.web>
<sessionState mode="SQLServer"
sqlConnectionString="data source=ServerName;user id=name;password=pwd"
cookieless="true"/>
</system.web>
</configuration>
Example 8-5 sets the mode
attribute to SQLServer, which uses an SQL Server
database called ASPState to store session state values to be shared
across multiple machines. This database is set up using the
InstallSqlState . sql batch
file installed by default in the directory
%windir%\Microsoft.NET\Framework\%version% ,
where %windir% is the Windows directory and
%version% is the version number of the installed
framework (the version number is prefixed with a
"v" in the actual path).The SQLServer mode requires the use of the
sqlConnectionString attribute. You should always override
this attribute, since its default uses the local 127.0.0.1 loopback
address and uses the SQL Server sa account to
connect to the ASPState database. Neither is a good practice in a
production application. In Example 8-5 set the data
source portion of the connection string to the name of the designated
SQL Server state machine and set the user ID and password to an
account set up to read and write state data.Example 8-5 also sets the
cookieless attribute to True,
anticipating that some users may have disabled cookies. Setting this
attribute to True places the session identifier
within the URL of all requests, allowing session use without cookies.
Note that applications designed for cookieless sessions should use
relative rather than absolute URLs for internal links.
