今天小编带大家一起来了解一下应用程序的授权许可。
1、在windows中授权。假如用户已经被成功地验证身份，如果所验证的账户拥有对该资源的正确的许可，则用户就可以访问他们所请求的资源。这种许可保留在每一个资源的ACL中。Windows采用一系列方法管理这些ACL。比如windows explorer用于在局域和网络驱动器上管理文件和文件夹的ACL。在windows explorer中打开任何文件或文件夹的properties对话框，选择security页，就可以显示已经访问了文件或文件夹的账户和组，以及它们的许可。Advanced按钮更详细地控制选项。
Windows验证提供最安全的方法，可以控制访问和保障ASP.NET应用程序的安全。但是，如果希望为几个应用程序建立登录的策略，则这种验证方法就无法使用，因为这些应用程序分布在不同服务器和站点中，尤其是在不同地理位置的站点。唯一的解决方案是在所有服务器上建立相同的账户，可行的方法是使用active directory建立windows“森林（forest）”，这样所有的服务器称为相同企业的一部分——即使这些服务器分布于不同域中也是如此。
但是，如果希望启用在多个站点间使用相同的证书用户的系统，这也可能失败。例如，可能希望构建解决方案，其中用户可以登录到一家著名的站点，比如hotmail.com，然后可以到达自己的站点，当证书记录在hotmail时，根据所提供的登录证书自动完成验证。
验证了用户之后，系统至少会知道一些用户的信息。至少会知道用户名称（身份）和所执行的验证类型。在windows验证的情况下，它也知道用户是哪一个成员的角色（即哪一个windows账户组）。
网站建设中我们可以在代码中访问此信息，并使用它处理应用程序的行为。例如，我们可以显示不同页或改变页的内容，这取决于特定的用户，或取决于他们所属于的组。这是一项非常有用的功能，因为唯一的替代方法是提供页内容，为此要创建页的多个副本，并建立正确的用户对每一页的访问许可。即使这样，用户可以知道他们应该访问哪一页的唯一方法也只是实验所有的页，这可不是方便用户的方法。
所有ASP.NET页和资源会默认地在局域系统进程账户之下运行——这些账户带有SYSTEM的绰号。此账户通常具有机器上的所有资源的完全权限，因此ASP.NET可以正常运行，而没有许可设置带来的问题。当然，我们可以修改此账户的许可，为此可以控制ASP.NET访问资源的方式。其他许多进程也可以使用SYSTEM账户，改变其许可可以导致其他应用程序无法运行。
相反，在此还有另一个绰号值可以使用，即MACHINE，其密码是AutoGenerate。当账户称为ASPNET时，就可以运行ASP.NET。此账户广泛地等同于普通的ASP账户（即它不拥有特权），但是ASP.NET为此账户设置了一些ACL，以帮助非常规地使用它。至少，ASP.NET需要读取它自己的二进制文件，配置文件（例如，安装root和安装root/config文件夹）的许可，并可以完全控制ASP.NET temporary file文件夹，安装进程可以自动设置这些。此选项可以在公共服务器上提供简单有效的方法，以强化安全。
元素提供账户细节，仅当为启用模仿设置时使用这些细节。打开模仿设置意味着ASP.NET会运行在账户环境之下，当接收请求时由IIS验证此账户。如果配置IIS来允许匿名访问（站点的默认设置），那么其环境是IUSR账户的环境（或者是所规定的账户，如果改变它，IIS就为匿名访问使用此账户）。简单地在machine.config或web.config文件的<system.web>部分添加<identity impersonate=”true”>元素，意味着会在IIS匿名账户（IUSR_machinename）之下发生匿名访问。另一种可能情况是使用<identity>元素的userName和password以规定账户，我们希望ASP.NET资源运行在此账户之下。
.NET Framework的原则是一旦创建了一个枚举对象，会在原处及时得到包含在可枚举对象的项目的快照。如果初始对象发生了改变，枚举就会无效，下次调用枚举对象的任何一种方法时枚举对象会抛出InvalidOperationException。所有的.NET Framework类都遵循这些原则，用户所写的枚举类型同样如此。然而，由于性能方面的原因，在创建可枚举对象时，架构中的枚举对象实际上并没有复制所有的项目。它们只是把引用保存回到可枚举对象中，并提供了一个逻辑快照。把一个引用和一个索引保存到初始枚举对象中比复制每个项目要廉价得多，对一个巨大的集合来说，复制项目是个非常昂贵的过程。
散列表根据散列代码唯一的识别关键字。散列代码是在合适的地方用来唯一地识别特殊类型的单个对象实例。一个理想的散列代码算法应该总是返回对于特殊类型的单个实例来说是唯一的散列代码。像数据库中的一行身份字段也可以较好地用作散列代码。Hashtable可以使用散列代码提供有效而又迅速的查找。在创建自定义类型时，必须采用比较优秀的散列代码算法。
如同.NET Framework类库中的大多数集合可以使用任何类型一样，System.Object类有一个名为GetHashCode的方法，该方法能够返回任何对象实例的散列代码。而系统所提供的该方法的实现方式也返回唯一的识别对象实例的散列代码，但该对象实例并不是具体于某一指定类型。返回的值仅仅是CLR内部保存的用来识别对象的索引。这就是说，如果类型没有重写GetHashCode由系统提供的实现方式，那么在默认状态下，如果两段散列代码的值一样，那就是同一个对象实例。
设计组件最困难的抉择之一就是选择使用什么接口。对于所有基于组件的架构来说都是如此——不仅仅是.NET。至于何时使用属性何时使用方法既是个人喜好，也有如下所述的一些基本原则：1、如果内部数据成员显示在组件外部时应该使用属性。2、由于执行代码而对组件或环境产生明显的副作用，就应该使用属性方法。3、如果代码执行顺序很重要，应使用属性方法。由于CLR能够短路表达式的测试，如果想访问属性恐怕就不能如愿了。
CLR中的属性允许开发人员将额外的信息添加到他们已创建的类中。对于应用程序而言，这些额外信息可以通过SZystem.Reflection类让使用组件的应用程序使用。属性可以给许多不同的使用我们的组件的系统提供提示或者标志。属性还可以作为编译器标志告诉编译器该如何处理类的编译。工具可以利用属性在设计时提供更多的关于组件用法的信息，这就意味着我们无需再往代码中加入注释，以上工具知道某些代码位于什么地方。属性在与操作系统的组件服务特性交互时，它还可以用来识别类的事务处理特征。
JSP页面不但包含处理请求和生成响应的代码，还有发向JSP编译器的指令。这些指令称为伪指令。此伪指令提供设置影响到页面解释和执行方式的属性方式。属性可按任意次序指定。在一个编译单元内（JSP页面和它使用include伪指令包含的任意文件）可以指定多个Page伪指令。如果使用了多个page伪指令，它们不能多次指定同一属性，但import属性除外。
JSP体系结构允许其被扩展成服务器端脚本的通用框架。为此，它在page伪指令中支持language属性。指定值（缺省为JAVA）应用于所有声明、表达式和当前转换单元内的scriptlet，包括在include伪指令中指定的任意文件。所有JSP兼容的容器必须支持language属性的JAVA取值。在JSP规范中不支持其他语言，但个别JSP引擎是可以的。
要定义标签，首先你要明白你定义标签的整体内容，要定义好标签需要掌握以下几个方面的内容：1、标签的名字，在定义标签的时候我们会看到，总是通过名空间修饰词使用定制标签，因此不必使标签名全局唯一。2、标签的属性，例如HTML<TABLE>标签可选属性为BORDER、CELLPADDING、CELLSPACING和WEDTH。定制标签可以定义任意数目的必须或可选属性，当执行标签时它们被传入标签处理器。3、标签的脚本变量，例如，标准行为<jsp:useBean id=”xyz” class=”jspcr.bcans.XYZBean”>使得类型为jspcr.beans.XYZBean名为xyz的变量被定义。此变量然后对<jsp:getProperty>和<jsp:setProperty>动作及下面任意scriptlet或表达式中JAVA代码可用。定制标签可以用同样方式创建脚本变量。
