魔站网站建设,网站开发和网站运营的区别,常德市建设网站,做cad室内平面图的家具素材网站上文我们了解了一个外部Http Request进入IIS 工作进程(W3WP)的处理与执行信任模型#xff0c;这个阶段是Sharepoint的四种执行模型都必须经过的处理阶段#xff0c;其中Sharepoint场解决方案与任何 ASP.NET 应用程序一样就是在 IIS 工作进程(w3wp)中运行的#xff0c;所以上… 上文我们了解了一个外部Http Request进入IIS 工作进程(W3WP)的处理与执行信任模型这个阶段是Sharepoint的四种执行模型都必须经过的处理阶段其中Sharepoint场解决方案与任何 ASP.NET 应用程序一样就是在 IIS 工作进程(w3wp)中运行的所以上文也就包含了场解决方案的处理与执行信任模型。 这里继续我们的话题就是看看Sharepoint的沙盒解决方案在这方面是什么情况。 沙盒解决方案是 SharePoint 2010 的新功能。沙盒解决方案是直接部署到网站集根网站中The top Website of the Site Collection的指定库的资源集合。此库称为解决方案库(Solution Gallery)。我们可以像场解决方案一样将沙盒解决方案打包为 SharePoint 解决方案包 (WSP)。不过可以通过 Web 用户界面 (UI) 直接上传 WSP 来部署沙盒解决方案而不必物理访问服务器文件系统也不必 IT 团队参与。相反网站集管理员确定谁有权限向其网站集添加沙盒解决方案。所以沙盒解决方案对开发和管理团队是很有诱惑力的。
一、IIS工作进程(w3wp)交权给执行管理器(Execution Manager) 如果用户的Http 请求(Http Request)中包含有对沙盒解决方案的处理模型Http请求到了IIS工作进程(w3wp), IIS工作进程(w3wp)就会发现这个请求里涉及到沙盒处理模型这时IIS工作进程(w3wp)就会调用它里面运行的执行管理器(Execution Manager)由执行管理器(Execution Manager)来接管下一步的处理权移交。如下图: 上图中的SPUCHostService.exe、SPUCWorkerProcess.exe 和 SPUCWorkerProcessProxy.exe 文件位于
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode。 二、执行管理器(Execution Manager)交权给沙盒工作进程(SPUCWorkerProcess) IIS 工作进程中运行的 SharePoint执行管理器(Execution Manager)负责查找沙盒解决方案的代码将在其中运行的沙盒工作进程(SPUCWorkerProcess)如果未运行任何沙盒工作进程则负责启动一个沙盒工作进程。 请注意执行管理器(Execution Manager)启动或定位的沙盒工作进程(SPUCWorkerProcess)并不一定是在同一服务器上这可以从上面的示意图中看出。
2.1沙盒工作进程(SPUCWorkerProcess) 宿主机的要求 一般而言执行管理器(Execution Manager)会在Sharepoint服务器场中任何运行 SharePoint Foundation 沙盒代码服务 (SPUCHostService: Sharepoint User Code Host Service) 的服务器上启动此沙盒工作进程(SPUCWorkerProcess)。 在 Windows服务对话框中它称作SharePoint 2010 用户代码主机服务如下图: SharePoint Foundation 沙盒代码服务(SPUCHostService)在服务器场帐户下运行此帐户与应用程序池帐户Application Pool Account拥有一样的权限此帐户归属于沙盒代码服务所运行的宿主服务器上的WSS_WPG、WSS_ADMIN_WPG、IIS_USERS这三个组。
2.2运行Microsoft SharePoint Foundation沙盒代码服务(SPUCHostService)物理服务器的定位模式 运行 SharePoint Foundation 沙盒代码服务的服务器可以是但并不一定是运行 IIS 工作进程的前端 Web 服务器。可在管理中心应用程序内配置要使用的服务器这种配置有两种选项。 I、本地模式(local mode):这意味着将在运行 IIS 工作进程(W3WP)的同一前端 Web 服务器上处理对沙盒解决方案的每个请求即本地处理。 II、远程模式(remote mode)有时称作相似性模式[affinity mode]:在此模式中启动每个沙盒进程执行管理器将查找运行 SharePoint Foundation 沙盒代码服务的服务器该服务器已在其 SPUCWorkerProcess进程内为相同的沙盒解决方案创建了 一个应用程序域(application domain)。如果其他网站集的另一个用户之前已请求该相同的沙盒解决方案则将出现此情况。如果存在一个匹配的应用程序域则会将请求发送到相同的应用程序域以进行处理。如果运行 SharePoint Foundation 沙盒代码服务的任何服务器都不具有沙盒解决方案的应用程序域则执行管理器会将请求分配给这些服务器中最闲的服务器。之后该服务器将创建所需的应用程序域并处理对沙盒解决方案的请求。 不管使用的是本地模式还是相似性模式沙盒工作进程中的应用程序域(application domain)都将在处理完请求后保持活动状态且如果存在对相同沙盒解决方案的其他请求则将重用该应用程序域。 默认情况下由给定服务器处理的所有沙盒解决方案都在相同的沙盒工作进程中运行但这种配置是可以通过object Model进行修改的。每个沙盒解决方案会在常规进程(common process)中获取其自己的应用程序域(application domain)而这种配置也是可以通过object Model进行修改的
2.3 运行Microsoft SharePoint Foundation沙盒代码服务物理服务器的分配方法 如果你的服务器场包含了若干台服务器那么你既可以在所有物理服务器上启动Microsoft SharePoint Foundation沙盒代码服务也可以只选择在某几台应用服务器上启动Microsoft SharePoint Foundation沙盒代码服务。 当然你也可以准备一台配置比较高的服务器加入到服务器场中专门用于运行Microsoft SharePoint Foundation沙盒代码服务。这样无论服务器场中的哪一台前端服务器需要运行沙盒解决方案中的自定义代码这些请求都会被发送到这台强大的物理服务器上进行处理。
三、沙盒工作进程(SPUCWorkerProcess) 内的代码执行和安全模型 前面我们提到沙盒方案其实就是一种受限方案正因为受限所以才安全。所以在沙盒工作进程(SPUCWorkerProcess)中运行的所有代码会受到执行和访问约束的限制。 这种约束有两个体系 3.1、第一个体系称作服务器端对象模型约束 此约束体系仅适用于沙盒解决方案中的代码对主 SharePoint Foundation 程序集即 Microsoft.SharePoint.dll的调用其调用只作用于Microsoft.SharePoint.dll中的部分object model。这种约束不仅仅是指从用户创建的Sharepoint Solution中调用Microsoft.SharePoint.dll而且还包括从Sharepoint的其它程序集(eg: Microsoft.Sharepoint.Linq.dll)来调用Microsoft.SharePoint.dll程序集。 3.1.1服务器端对象模型约束体系中的主要限制是: 只能从沙盒解决方案调用 Microsoft.SharePoint.dll 程序集中的部分 API。调用任何禁止的 API 会引发异常将捕获该异常并将其作为错误报告给用户。 以下是可访问的 SharePoint 对象模型的一些限制
SPWebApplication 类不可用。此外这意味着沙盒解决方案无法访问其托管网站集外部的任何内容。Microsoft.SharePoint.WebControls 命名空间中的所有类几乎都不可用这意味着您只能使用沙盒解决方案中的 ASP.NET 控件。3.1.2 服务器端对象模型约束通过以下机制来施加: 此限制由一对位于%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies 中的特别受限版本的 Microsoft.SharePoint.dll 程序集称作填充程序 程序集实现。这两个版本与标准 Microsoft.SharePoint.dll 程序集的主要差异是它们仅包含标准版本中的部分类和成员。 这两个填充程序程序集之一由沙盒工作进程(SPUCWorkerProcess)加载另一个填充程序程序集在完全信模式下运行的特殊代理进程 (SPUCWorkerProcessProxy) 中加载并由 SharePoint Foundation沙盒代码服务(SPUCHostService)管理。 此外标准 Microsoft.SharePoint.dll 程序集也在此代理进程中加载。 这两个填充程序程序集的主要工作是: I、筛选出禁止的 SharePoint 类和成员 在从沙盒工作进程中的任何代码调用 Microsoft.SharePoint.dll 时它将重定向到程序集的填充程序版本。如果要调用的 API 未在填充程序程序集中则将引发异常将捕获该异常并将其作为错误报告给用户。 当沙盒解决方案调用填充程序程序集中包含的已批准的 API 时第一个填充程序程序集会(它由沙盒工作进程SPUCWorkerProcess加载)在完全信任代理进程中将此 API 传递给第二个填充程序程序集它由特殊代理进程 (SPUCWorkerProcessProxy)加载而第二个填充程序程序集会将此 API 传递给标准 Microsoft.SharePoint.dll。任何返回的结果将传递回原始调用代码。可通过 .NET 远程来实现此跨进程交互。 沙盒工作进程和完全信任代理进程总是一起启动并成对出现。如果其中一个进程崩溃则另一个进程也会停止。 II、对传递给Sharepoint API的参数进行特殊限制 该限制也由填充程序程序集强制实施。我们可似从沙盒解决方案中调用某些 SharePoint API但只会将针对参数的特殊限制传递给这些 API。这些输入限制由填充程序程序集强制实施并确保在发生冲突时引发异常。在 SharePoint Foundation 2010 中仅 SPSite(String) 和 SPSite(Guid) 构造函数属于此应用情况。虽然它们对沙盒解决方案可用但只能将引用安装了沙盒解决方案的网站集的 URL 或 GUID 传递给它们。 因为第二个填充程序程序集和标准 Microsoft.SharePoint.dll 在完全信任的进程中运行所以上述限制就不 适用于对 Microsoft.SharePoint.dll 程序集中的 API 的调用更进一步说就是通过这些API就可以完成某些在沙盒方案中被禁止的操作。比如: 对 GetLocalizedString 方法的调用可从文件系统中的资源文件读取而对 SPList 对象的调用可读取并写入到内容数据库中无论其所在的服务器如何。但是不能将文件部署到沙盒解决方案中的磁盘因此必须将 .resx 作为场解决方案单独安装。 3.2、第二个体系称作一般约束 此约束体系适用于所有其他 调用包括对所有其他 SharePoint 程序集和 .NET Framework 程序集的调用只要不是对主 SharePoint Foundation 程序集即 Microsoft.SharePoint.dll的调用就行。 上面这两个体系是互斥的一般约束不 适用于对 Microsoft.SharePoint.dll 程序集的调用你只能二选 一。此外还有一些由沙盒解决方案中使用的分页呈现系统产生的杂项约束。 一般约束通过两种机制来施加 I、第一种机制 是通过在wss_usercode.config 文件所定义的高度限制的 CAS 策略来大大限制沙盒工作进程中可执行的代码此文件在%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG 中定义,并在 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode 下的 web.config 文件中引用了该策略。微软不支持更改此文件。由 CAS 策略施加的限制如下
沙盒中的代码不能调用非托管代码。沙盒中的代码不能调用 Microsoft .NET Framework 3.5 反射 API。沙盒中的代码只能调用具有 AllowPartiallyTrustedCallersAttribute 属性的 .NET Framework 3.5 程序集。这将阻止对约三分之二的 .NET Framework 3.5 API例如包括 System.Printing的访问。此外一些 SharePoint 程序集不具有此属性。CAS 策略将强名称 Microsoft Office 程序集视作例外。这些程序集授予了完全信任。 II、第二种机制 是通过安全令牌来实施即给沙盒工作进程赋予一个低权限的安全令牌。
该令牌拒绝进程对文件系统进行读取或写入的权限。该令牌拒绝进程对网络进行调用的权限。因此只能访问运行沙盒工作进程的服务器上可用的资源。例如无法访问外部数据库。该令牌拒绝进程对注册表进行写入的权限。该令牌拒绝对未在常规程序集缓存(GAC)中的任何程序集进行调用的权限即使它具有 AllowPartiallyTrustedCallersAttribute 属性也是如此否则它将符合从沙盒工作进程进行调用的资格。沙盒解决方案自身的部署阶段在沙盒工作进程中运行并受相同执行约束的限制。例如在部署沙盒解决方案时无法将文件部署到磁盘。这是用户控件ASCX 文件不能位于沙盒解决方案中的主要原因。 四、关于沙盒方案资源使用的限制 沙盒方案既然把一定的权力下放但由此却带来潜在的问题那就是对Sharepoint资源的分配。设想如果不加控制那么某个用户就可能把特定的资源消耗殆尽。所以Sharepoint也就自然引入了针对资源的使用限制具体有如下三条限制规则
每个请求请求遭到处罚对于完成沙盒解决方案所需的时间有一个硬性限制。默认情况下此时间限制为 30 秒。如果沙盒解决方案超出了该限制则将终止请求而非沙盒工作进程。此限制是可配置的但只能通过针对对象模型的自定义代码进行此操作。对象模型的相关部分对沙盒解决方案不可用因此任何沙盒解决方案都无法更改此限制。每个请求进程遭到处罚有一组适用于请求的附加资源限制共 15 条。如果请求超出某个限制则将终止进程以及进程中运行的所有 沙盒解决方案。每天/每个网站集网站集遭到处罚每个网站集均受可配置的每日资源点最大数的限制。这些点基于某种算法进行累计该算法会考虑网站集中安装的沙盒解决方案对 15 类资源的使用。当网站集超出其允许的最大点数时该网站集中的所有沙盒解决方案将终止且在剩余时间内再也无法运行。
五、沙盒的分页呈现 当客户端计算机请求包含沙盒解决方案中的组件例如沙盒解决方案中部署的 Web 部件的 SharePoint 页时SharePoint 会呈现多个页对象。其中一个页对象在 Microsoft ASP.NET 工作进程 (w3wp.exe) 中呈现而其他页对象在沙盒工作进程中呈现。所有非沙盒组件会在 ASP.NET 工作进程中的页上呈现而第一个沙盒组件会在沙盒工作进程中的一个页对象上呈现。在完全呈现沙盒工作进程中的该页时会将该页并入 ASP.NET 进程中的页对象。如果用户请求的页上有多个沙盒组件则将在这些组件在沙盒工作进程中所对应的页对象上单独呈现它们。反过来每个此类页对象将并入 ASP.NET 进程中的页对象。
六、摆脱沙盒限制 沙盒解决方案可通过两大方式摆脱常规限制。 1.使用客户端代码访问无法从沙盒解决方案中的服务器端代码访问的资源。 例如沙盒解决方案可包含带 JavaScript 的自定义网页JavaScript 可调用 SharePoint 的 JavaScript 客户端对象模型。此外沙盒解决方案可包含承载 Microsoft Silverlight 应用程序的 Web 部件。后面的应用程序可调用 SharePoint 的 Silverlight 客户端对象模型。沙盒解决方案上的任何限制都不适用于客户端代码。不存在以下限制代码执行限制、资源访问限制和资源使用率限制。 2.通过完全信任代理。 即开发一个服务器场解决方案它包括派生自 SPProxyOperation 的一个或多个类其中的每个类均定义一个将在完全信任下运行的操作并且可通过 ExecuteRegisteredProxyOperation 方法从沙盒解决方案中调用这些类。具体而言将在运行标准 Microsoft.SharePoint.dll 程序集的相同代理进程 (SPUCWorkerProcessProxy.exe) 中执行这些完全信任代理操作。代理操作可将数据返回到沙盒解决方案。
七、Sharepoint执行的其它情况 并不是所有的Sharepoint 实施都依赖于IIS工作进程(IIS worker process),沙盒工作进程(sandboxed worker process)或其代理进程(proxy process)。下面就是一些例子:
Sharepoint的Timer Service,用于执行预设的作业它可以影响其它服务它以Farm帐户运行在owstimer进程下。SharePoint的Tracing Service 以本地的服务帐户(local service account)运行在wsstracing进程下。SharePoint Administration Service 以本地系统帐户(local system account)运行在wssadmin进程下。
