Sharepoin学习笔记—架构系列--Sharepoint的网页(Page)，网页解析(Parsing)与解析安全处理(Security)

Microsoft SharePoint Foundation 中主要有两种类型的页面，分别是应用程序页(Application Page) 和网站页(Site Page)。

   应用程序页(Application Page) 和网站页(Site Page)都从同一母版页继承其布局。

   应用程序页(Application Page)与传统的 Microsoft ASP.NET 3.5 网页最为相似。但是，应用程序页面并非直接派生自System.Web.UI.Page，而是派生自 LayoutsPageBase 或 UnsecuredLayoutsPageBase。应用程序页面不在安全模式下运行，并且可能包含内嵌代码。只有场管理员可以安装应用程序页面。

   网站页(Site Page)是由最终用户创建、编辑和自定义的页面，是可以由用户个性化定制与修改的页面。网站页是通过存储在前端 Web 服务器（Front-End Web Server）的文件系统上的模板页面设置的。在设置网站时，SharePoint Foundation 会创建指向文件系统上的页面模板实例的指针，这个指针存放在使用了此网站页的Website的Content Database中。这样，SharePoint Foundation 就可以避免重复创建每次创建网站时都要设置的页面的副本。

                            网站页(Site Page)具有两种类型 - 标准页(Standard Page)和 Web 部件页(Web Part Page)。

     标准页(Standard Page)包含文本、图像、Web 部件及其他元素。这些页面是启用 wiki 的页面，可以包含 Web 控件和内嵌 Web 部件。标准页(Standard Page)派生自 WikiEditPage 类，而不直接派生自 System.Web.UI.Page。

     Web 部件页(Web Part Page) ：顾名思义，它们是包含 Web 部件区域(Web Part Zone)的 Web 部件(Web Part)页。Web 部件页(Web Part Page)派生自 WebPartPage，而不直接派生自 System.Web.UI.Page。

     Sharepoint2010中加入了第三种网站页（Site Page）：PublishingPage，这种页面只使用在发布网站(Publishing Sites)中。在发布网站中，作者和批准者(Author and Approvers)使用发布功能(Publishing Feature)来创建内容以提供给网站用户访问。通常来说，一个发布网站都会绑定有Approval工作流，这样待发布的内容才能在正式发布前把握质量。Publishing Pages通常基于Page layouts这样的页面模板创建，Page Layouts提供了一致性的结构给Publishing Pages，并且它是可以被客户化定制的。

     Sharepoint还包括一套内建的用于移动设备的网页。SharePoint Foundation 移动网页比非移动网页简单得多。移动网页不使用 ASP.NET 母版页/内容页技术，也不划分为应用程序页面和网站页面。SharePoint Foundation 移动网页都是应用程序页面，且位于 \_layouts\Mobile 文件夹中。SharePoint Foundation 移动网页在某个方面特别类似网站页面：如果页面包含移动的 Web 部件适配器，则必须将该适配器注册为安全控件，否则将不呈现该适配器

上面对Sharepoint的网页情况作了大致说明

下面让我们来重点比较一下应用程序页(Application Page)与网站页(Site Page)，看看它们具体的区别:

1、应用目的(Typical purpose):

    应用程序页( Application pages)侧重于"功能"实现（function-oriented），比如象提供给用户的用于创建一个新的Web Application的页面那就是应用程序页，你在那个创建页面上输入所需的参数，然后再点确定，从而创建一个新的Web Application。

    而网站页（Site Pages）则侧重于"内容"实现（Content-oriented），比如像在标准的Team Site中给用户展示当前网站都有哪些list的页面就是网站页。

    当然，这种区分并不是强制性的，有时也有混用的情况，第三方可以开发一个用户定义的Web Part，在这个Web Part上实现一些特定的用户操作功能(eg:List管理功能，信息处理功能…，就像你一般的应用程序处理界面上的那些功能一样)，然后再把这个Web Part加载到网站页，从而让网站页也具有了"功能"操作性。有时这种方式比开发一个应用程序页更灵活，也更便捷。

2、用户定制能力(Customizability):

     网站的所有者(owner)以及拥有相应权限的用户可以对网站页(Site Page)进行用户定制修改，用户还可以添加一个新的ASCX页面到网站页陈列区（Site Pages Gallery）。

     但用户却无权对应用程序页(Application Page)进行定制与修改，只有管理员才有权限安装一个新的应用程序页到网站上来。

3、继承基类(Class inheritance):

    应用程序页( Application pages)继承自 LayoutsPageBase 类 或者UnsecuredLayoutsPageBase 类。

    网站页（site pages）继承自 WikiEditPage 类或 WebPartPage 类.

    而所有上面提到的基类又都继承自ASP.NET的 Page 类.

4、Web 部件支持(Web Part support):

    应用程序页( Application pages)没有Web Part Zone或者动态的Web Parts，但它可包含静态的Web Parts，可这种静态的Web Parts没多少实用价值，因为开发者完全可以采用传统控件来实现要在此页面上完成的功能。

    网站页（Site pages）既可以包含静态Web Parts也可以包含动态Web Parts和Web Part Zone。

5、存储位置(Storage location):

    应用程序页( Application pages)存储在前端Web服务器(Front-End Web Server)的文件系统上，其位置是在对应的Web Application的_Layouts虚拟目录(Virtual Directory)下,此虚拟目录会映射到(Map to)服务器文件系统的实际磁盘目录上，此目录是 :%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS 目录或其子目录。

     网站页(Site Page)通常根据它们是否已经被进行了定制来分为Uncustomized Page和Customized Page两种（在SPS2003中，使用的是Ghosted Page和Unghosted Page这两个术语）,具体说明如下

           I、网站页没有被客户个性化定制修改：当我们新建一个站点的时候，所有的页面都是Uncustomized Page，这些页面都是直接使用了存放在前端 Web 服务器（Front-End Web Server）磁盘上的页面模板（位于%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE目录及其子目录(eg: SiteTemplates与Features子目录就是常用的子目录)，换言之，这个新站点的页面其实是"不存在的"，它们只是一个"标记"（这也就是在SPS2003中，它们被称为Ghosted Page的原因），如果用户访问一个页面，SharePoint会自动从磁盘上找到那个真正的页面模板文件，然后将其载入到内存中，解析它，并将其编译成一个独立的DLL文件（为了性能，这个DLL会缓存在磁盘上以避免下次重复编译），然后载入这个DLL并运行和输出.

          II、网站页被个性化定制或修改：一旦网站页被Microsoft SharePoint Designer这样的工具修改，那么SharePoint会自动将修改后的文件内容保存到站点所用的内容数据库(Content Database)中，它就成了一个Customized Page。当用户访问这个页面时，SharePoint会自动从内容数据库中读出这个文件的内容，然后对其进行解析，运行。这种情况下，SharePoint不会再将其编译成一个独立的DLL文件，实际上，SharePoint会在内存中载入这个页面的结构，运行，然后输出，然后将它从内存中卸载以节省内存。

         注：Uncustomized Site Page虽然存放在文件系统中，但实际上它在Content Database中也会有记录，这个记录主要用于保存.aspx页面文件的存放路径，这就是指向文件系统上的页面模板实例的指针。为什么会这么做呢，那是因为Uncustomized Site Page通常会被若干个Website共享，所以，凡是调用到此Uncustomized Site Page的Website就会在它们的Content Database中存放此Page的路径。例如：每一个Team Site的Content Database都会有记录指向Team Site的Home Page，这个HomePage就是Uncustomized Site Page，当打开TeamSite的相关网页时，系统就会根据此处存放的HomePage的路径把HomePage调取并显示出来。当然，如果有网站对此HomePage进行了个性化的修改，那么它会变成了Customized Page，于是相关修改内容就会保存进Content Database，而原先Content Database中保存的路径记录就会被移除。不过，可以通过 Web 浏览器或 SharePoint Designer 之类的工具将自定义页面重置为原始模板页面，即放弃用户的个性化定制，重新使用以前的页面模板，这样一来，在Content Database中又会重新存放指向文件系统上的页面模板实例的指针记录。 有的时候，Uncustomized Site Page会被做为模板(Page Template)被存放在Content Database中的页面实例所引用。总之记住：只要网站上的页面没有被个性化定制或修改，那么放在Content Database中的记录就只是一个路径指针用于指向这个页面在文件系统中的存放路径的。

6、可访问性(Availability):

    一个应用程序页(Application Page)可以被其所在的WebApplication中的任何Website访问到。

    而一个网站页(Site Page)通常却只能被它所部署的网站中的用户访问到，虽然我们前面提到Uncustomized site pages也可以被多个Website访问到，但这需要特定的手段才能做到（那些网站需要被做为Feature的一部分或Site Definition的一部分提供出来）。

7、解析模式(Parsing mode):

    应用程序页(Application Page)通过"直接(Direct)"方式进行解析。所谓直接方式就是指通过标准的ASP.NET页面解析器进行解析，当这个网页首次被访问时，它就会被解析器解析(Parsed)、编译(Compiled)，并缓存在前端 Web 服务器（Front-End Web Server）的内存中，直到此请求所关联的application domain或IIS被回收清空(recycled)。如果在回收前有其它访问请求，那么它就会直接从缓存中提供给请求者而无需重新进行解析、编译的过程。

    网站页(Site Page)分两种情况 ：

        I、Uncustomized site pages也是通过"直接(Direct)"方式进行解析。

        II、而customized site pages与添加到陈列区(Site Page Gallery)的新建网页则是通过"安全模式(Safe Mode)"进行解析的。

        安全模式(Safe Mode)解析特点如下:

         (i)、只有在Web Application的Web.config文件中注册为"安全(Safe)"的控件(包括Web Parts)才能被解析和呈现。

         (ii)、内联服务器端代码(Inline server-side code)在安全模式下是不允许的，如果你在网页中嵌入了内联服务器端代码，那么系统会返回给你一个报错页面。 所谓内联服务器端代码如下: 

< script  runat ="server" >  
[code is here] 
</ script > 
或 
< asp:button  OnClick ="MyButtonHandler()"   /> 

              对于后台代码(Code behind)和内嵌的JavaScript(embedded Javascript)是被允许的，因为它会被编译成单独的程序集并部署。

        (iii)、这种Customized Site Page网页与直接模式处理的应用程序页是不同的，因为它不像应用程序页一样需要被系统编译，因此，如果在此类网页中加入诸如编译指令之类的东西都是不起作用的。

     需要注明的是，这里的安全模式解析(safe mode parsing)与Sharepoint其它文档提到的安全模式处理(safe mode processing)和安全模式呈现(safe mode rendering)其实指的都是同一件事。

     Sharepoint为什么会引入这种安全模式呢?

     你可以想想，既然允许用户个性化定制，那么就必须涉及到网页行为的定制，由此产生的问题就是：用户可能在个性化过程中加入执行代码，如果这些代码既安全又高效那也没什么，但谁又能保证所有用户都做到这点呢。还有就是这种网页不能被编译，这也不难理解，试想如果有成百上千个用户都做了个性化定制，而这种个性化定制的网页都必须要通过重新编译才能呈现，那么我们的服务器将承受多大的压力，并且这些被编译的结果要放到服务器内存中缓存，这个缓存的内容只能通过回收application domain来清除，但问题是回收application domain就会清空程序集，程序集中还包括了其它网页内容，你做不到仅仅清空你想要移除的那个特定用户定制的网页，要么都清空，要么都保留，这显然是不合理的。此外在一个application domain中可以加载多少个程序集，在系统中也是有限制的。所以，所有这些因素都决定了为什么Sharepoint会引入安全模式解析，并且此解析方式为什么要按如此的规则开展工作。

     我们在前面提到：内联服务器端代码(Inline server-side code)在安全模式（Safe Mode）解析下是不允许的，其实准确的说应该是在"通常情况"下是不允许的。其实Sharepoint也不是那么绝情，它也留得有退路，它允许你通过修改Web Application的Web.config来实现允许内联服务器端代码或不安全控件，也即：向Web.config中的<Sharepoint>节点下的<SafeMode>元素中添加<PageParserPath>子元素，通过设置此元素的相关属性来指明要向哪个网页中添加内联服务器端代码或非安全控件(unsafe contrl)。显然这样作是比较危险的，所以你必须要非常小心,因为这种解禁可以是单个特定页面，也可以是整个目录的页面。添加 PageParserPath 设置将使可将页面上载到指定文件夹的任何人都能将任意的完全信任代码写入服务器。所以管理员在提供这些设置时应格外小心，要提前了解此操作存在的安全隐患，尽量保证系统的安全与性能。

     一种威胁的例子：

     如果你允许所有以 GetInfo*.aspx模式命名的网页添加内联服务器端代码，那么别有用心者就会个性化一个攻击性网页并以GetInfoAsMyMind.aspx来命名，此命名当然能通过Sharepoint的查检规则并获得运行相关代码的权力，结果就是对你的系统进行攻击与伤害。

     下面的示例演示使用通配符的 PageParserPath 设置。

      添加此 PageParserPath 将允许对母版页样式库具有权限的任何人上载服务器端代码。在添加此类型的 PageParserPath 设置时要格外小心。

< SharePoint > 
< SafeMode  ... > 
< PageParserPaths > 
< PageParserPath  VirtualPath ="/_mpg/*"  CompilationMode ="Always"  AllowServerSideScript ="true"  IncludeSubFolders ="true" /> 
</ PageParserPaths > 

     至于非安全控件(Unsafe control)是指通过编辑工具(Editing Tool)添加的控件（如：通过Sharepoint Designer添加的控件）。而至于WebPart则不管使没使用<PageParserPath>元素来开启(enable)非安全控件(Unsafe Control)，都必须要注册为安全才能被允许。

    你还可以通过使用<PageParserPath>元素来开启允许用户定制网站页(Customized Site Page)的可编译功能。这样这个网页就会被编译成DLL并存放到缓存中，显然这种做法就类似于应用程序页(Application Page)的编译方式了，这样做的好处就是加快此网页的访问响应速度。所以，它只针对那些经常会被访问到的网页有效。    

 

 

欢迎转载本人原创博文，但在转载时请务必保持原文全貌，并以超链接形式标明文章原始出处和本声明。否则将追究法律责任