ASP.NET2005 Web.config详解

来源:互联网 发布:日本自由行 知乎 编辑:程序博客网 时间:2024/04/30 06:59

<?xml version="1.0" encoding="utf-8" ?>
<configuration> 所有.NET配置文件所必须的根元素
<system.web> 实际ASP.NET配置设置的根元素

<!-- 动态调试编译
设置 compilation debug="true" 以启用 ASPX 调试。
否则,将此值设置为 false 将提高此应用程序的运行时性能。
设置 compilation debug="true" 以将调试符号(.pdb 信息)插入到编译页中。
因为这将创建执行起来较慢的大文件,所以应该只在调试时将此值设置为 true,而在所有其他时候都设置为false。
defaultLanguage="c#" 指定动态编译时使用的默认编程语言,它的值可以是compilers标记定义的任何语言。
tempDirectory 指编译过程中存储文件的目录
-->

<compilation defaultLanguage="c#" debug="true" />

<!-- 自定义错误信息
设置 customErrors mode="On" 或 "RemoteOnly" 以启用自定义错误信息,
或设置为 "Off" 以禁用自定义错误信息。 为每个要处理的错误添加 <error> 标记。
"On" 始终显示自定义(友好的)信息。
如果没有提供defaultRedirect属性,则用户将看到一般的错误信息.
"Off" 始终显示详细的 ASP.NET 错误信息。显示全部的错误细节
"RemoteOnly" 只对不在本地 Web 服务器上运行的用户显示自定义(友好的)信息。
出于安全目的,建议使用此设置,以便不向远程客户端显示应用程序的详细信息。
-->

<customErrors mode="RemoteOnly" />

使用customErrors 元素,可以配置应用程序响应各种HTTP错误时的行为。
例如,通过如下代码,当发生404错误时,就可以把页面重新导向一个友好的页面。

<customErrors defaultRedirect=”standarderror.aspx” mode="remoteonly">
<error statuscode=”404” redirect=”filenotfound.htm”/>
</customErrors>

当发生HTTP错误时,上面的代码将把用户导向standarderror.aspx页面。
如果错误是代码404(即没有发现文件),将把用户导向filenotfound.htm。
但是,由于模式设置为remoteonly,所有本地的管理员将会看到真实的错误信息,
而不是被导向其它的页面,但远程的客户将会看到自定义的错误页面。

<!-- 身份验证
此节设置应用程序的身份验证策略。
可能的模式是 "Windows"、 "Forms"、 "Passport" 和 "None"
"None" 不执行身份验证。
"Windows" IIS 根据应用程序的设置执行身份验证 包含全部的IIS身份验证,此外,NTFS在文件和目录上的权限将决定对目录中资源的访问。
(基本、简要或集成 Windows)。在 IIS 中必须禁用匿名访问。
"Forms" 您为用户提供一个输入凭据的自定义窗体(Web 页),
然后在您的应用程序中验证他们的身份。用户凭据标记存储在 Cookie 中。
使用cookies去指出授权用户。
"Passport" 身份验证是通过 Microsoft 的集中身份验证服务执行的,
它为成员站点提供单独登录和核心配置文件服务。
-->

<authentication mode="Windows" />

下面是使用Passport的身份验证的示例。
在这个对目录进行配置的示例中,如果用户没有提供有效的Passport,则把用户导向login.aspx页面。

<authentication mode=”Passport”>
<passport redirectUrl=”login.aspx”/>
</authentication>

下面的示例阐明了怎样使用基于窗体的身份验证,以及怎样把有效的用户名和密码保存在配置文件中:

<authentication mode=”Forms”>
<Forms name=”SecureApplication” loginUrl=”/secureapplication/custlogin.aspx/”>
   <credentials passwordFormat=”Clear”>
    <user name=”admin” password=”admin”/>
   </credentials>
</forms>
</authentication>

<!-- 授权
此节设置应用程序的授权策略。可以允许或拒绝不同的用户或角色访问应用程序资源。
通配符: "*" 表示任何人,"?" 表示匿名(未经身份验证的)用户。
-->

<authorization>
<allow users="*" /> <!-- 允许所有用户 -->
<!-- <allow users="[逗号分隔的用户列表]"
roles="[逗号分隔的角色列表]"/>
<deny users="[逗号分隔的用户列表]"
roles="[逗号分隔的角色列表]"/>
-->
</authorization>

<!-- 应用程序级别跟踪记录
应用程序级别跟踪为应用程序中的每一页启用跟踪日志输出。
设置 trace enabled="true" 可以启用应用程序跟踪记录。
如果 pageOutput="true",则 在每一页的底部显示跟踪信息。
否则,可以通过浏览 Web 应用程序根目录中的 "trace.axd" 页来查看应用程序跟踪日志。
-->

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

默认状态下,trace元素处于激活状态,但是它的输出没有显示给Web页面。
在trace元素中也可以定义侦听器,侦听器其实是一些对象,使用那些对象,可以收听、收集和发送各种消息。
下面代码中定义的侦听器可以把跟踪信息写到日志文件(即文本文件中):

<trace enabled="true" requestLimit=”10” pageOutput=”false”>
<listeners>
   <add name=”TraceListener” type=”System.Diagnostics.TextWriterTraceListener,System”
    initializeData=”TraceListener.log”/>
</listeners>
</trace>

<!-- 会话状态设置
默认情况下,ASP.NET 使用 Cookie 来标识哪些请求属于特定的会话。
如果 Cookie 不可用,则可以通过将会话标识符添加到 URL 来跟踪会话。
若要禁用 Cookie,请设置 sessionState cookieless="true"。
-->

默认状态下,ASP.NET通过发送用户cookies(当用户关闭他们的浏览器时,cookies将终止),对会话状态进行维护。

<sessionState mode="InProc" 指ASP.NET会话状态的维护工作是在本地进行的。
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"
/>

<!-- 全球化
此节设置应用程序的全球化设置。
-->

Web站点的用户经常要发送和接收文本,这是文本编码格式的配置,默认是rtf-8。

<globalization requestEncoding="GB2312" responseEncoding="GB2312" />
</system.web>

AppSettings元素

<appSettings>元素处于<system.web>根配置之外,它是<configuration>部分的一个子元素。
通过简单的指定一对名称/值,就可以添加配置设置。如:

<appSettings>
   <add key="websitename" value="My New WebSite"/>
   <add key="welcomemessage" value="Welcome to my new Website,friend!"/>
</appSettings>
</configuration>

ASP.NET中客户端Session状态的存储

在ASP.NET中客户端的Session信息存储方式分为:Cookie和Cookieless两种。
ASP.NET默认状态下,在客户端还是使用Cookie存储Session信息的。
如果我们想在客户端使用Cookieless的方式存储Session信息的方法如下:

找到当前Web应用程序的根目录,打开Web.Config文件,找到如下段落:
  mode="InProc"
  stateConnectionString="tcpip=127.0.0.1:42424"
  sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
  cookieless="false"
  timeout="20" />

这段话中的cookieless="false"改为:cookieless="true"
这样,客户端的Session信息就不再使用Cookie存储了,而是将其通过URL存储。

当mode的值是InProc时,说明服务器正在使用这种模式。服务器将Session信息存储在IIS进程中。
当IIS关闭、重起后,这些信息都会丢失。但是这种模式也有自己最大好处,就是性能最高。
应为所有的Session信息都存储在了IIS的进程中,所以IIS能够很快的访问到这些信息
这种模式的性能比进程外存储Session信息或是在SQL Server中存储Session信息都要快上很多。
这种模式也是ASP.NET的默认方式。

服务器Session信息存储在进程外

打开管理工具->服务,找到名为:ASP.NET State Service的服务,启动它。
实际上,这个服务就是启动一个要保存Session信息的进程。
启动这个服务后,你可以从Windows任务管理器->进程中看到一个名为aspnet_state.exe的进程,这个就是我们保存Session信息的进程。

然后,回到Web.config文件中上述的段落中,将mode的值改为StateServer。
保存文件后的重新打开一个IE,打开SessionState.aspx页面,保存一些信息到Session中。
这时,让我们重起IIS,再回到SessionState.aspx页面中查看刚才的Session信息,发现没有丢失。

实际上,这种将Session信息存储在进程外的方式不光指可以将信息存储在本机的进程外,还可以将Session信息存储在其他的服务器的进程中。
这时,不光需要将mode的值改为StateServer,还需要在stateConnectionString中配置相应的参数。
例如你的计算你是192.168.0.1,你想把Session存储在IP为192.168.0.2的计算机的进程中,就需要设置成这样
stateConnectionString="tcpip=192.168.0.2:42424"。
当然,不要忘记在192.168.0.2的计算机中装上.NET Framework,并且启动ASP.NET State Services服务。

将服务器Session信息存储在SQL Server中

启动SQL Server和SQL Server代理服务。
在SQL Server中执行一个叫做InstallSqlState.sql的脚本文件。
这个脚本文件将在SQL Server中创建一个用来专门存储Session信息的数据库
及一个维护Session信息数据库的SQL Server代理作业。
我们可以在以下路径中找到那个文件:
[system drive]/winnt/Microsoft.NET/Framework/[version]/

然后打开查询分析器,连接到SQL Server服务器,打开刚才的那个文件并且执行。
稍等片刻,数据库及作业就建立好了。
这时,你可以打开企业管理器,看到新增了一个叫ASPState的数据库。
但是这个数据库中只是些存储过程,没有用户表。
实际上Session信息是存储在了tempdb数据库的ASPStateTempSessions表中的
另外一个ASPStateTempApplications表存储了ASP中Application对象信息。
这两个表也是刚才的那个脚本建立的。
另外查看管理->SQL Server代理->作业,发现也多了一个叫做ASPState_Job_DeleteExpiredSessions的作业
这个作业实际上就是每分钟去ASPStateTempSessions表中删除过期的Session信息的。

接着,我们返回到Web.config文件,修改mode的值改为SQLServer。
注意,还要同时修改sqlConnectionString的值,格式为:
sqlConnectionString="data source=localhost; Integrated Security=SSPI;"
其中data source是指SQL Server服务器的IP地址,如果SQL Server与IIS是一台机子,写127.0.0.1就行了。
Integrated Security=SSPI的意思是使用Windows集成身份验证
这样,访问数据库将以ASP.NET的身份进行
通过如此配置,能够获得比使用userid=sa;password=口令的SQL Server验证方式更好的安全性。
当然,如果SQL Server运行于另一台计算机上,你可能会需要通过Active Directory域的方式来维护两边验证的一致性。
Session信息存在SQL Server中,即使你重起计算机,刚才的Session信息也不会丢失。
现在,你已经完全看见了Session信息到底是什么样子的了,而且又是存储在SQL Server中的,能干什么就看你的发挥了

 

原创粉丝点击