ASP.NET Word/Excel 权限问题

在部署Word/Excel到服务器的时候,经常会碰到权限问题.例如;

  Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 8000401a 因为配置类型不正确，系统无法开始服务器进程。请检查用户名和密码。 (Exception from HRESULT: 0x8000401A).

 

  Retrieving the COM class factory for component with CLSID {3AACC1CC-7377-11D5-B316-0800309CC2CE} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

   类似这种错误,网上搜一搜,会有一大堆的答案.大部分是与权限相关,而且大多建议试用asp.net模拟权限的方法解决.

在web.config中配置:

<identity impersonate="true" userName="XXX" password="XXX"/>

配上管理员的账号和密码,即可正常试用了.但是这样的方法合适吗?让asp.net以管理员身份运行,总觉得会有安全隐患.

   这次因为研究分布式存储的原因,在两台服务器之间通过虚拟目录共享了文件夹,将IIS App Pool的运行账户使用了特定的用户.

就引起了权限上的问题.正好弄明白一下.

   通过Google,发现Word/Excel其实不适合做自动化:

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

参考:http://stackoverflow.com/questions/8708653/error-reading-word-doc-using-micorsoft-office-interopobject-library-via-iis-7

 

再找到MS的官方文档:

Microsoft Office 所有当前版本的设计、测试和配置都是为在客户端工作站上作为最终用户产品运行而完成的。它们假定存在一个交互式桌面和用户配置文件，而且不提供满足为以无人参与方式运行而设计的服务器端组件的需要所必需的重入或安全性级别。

Microsoft 目前建议不要从任何无人参与的、非交互式客户端应用程序或组件（包括 ASP、DCOM 和 NT Service）中进行 Microsoft Office 应用程序的“自动化”，也不为此提供支持，因为 Office 在这种环境中运行时可能会出现不稳定的现象并且/或者会死锁。

如果您要构建在服务器端上下文中运行的解决方案，应尽可能尝试使用对于以无人参与方式执行很安全的组件，或找到至少允许一部分代码在客户端运行的备选方案。如果您选择从服务器端解决方案中运行 Office 应用程序，将发现这样会缺少成功运行所必需的许多功能，而且整体解决方案的稳定性会有风险。

使用服务器端 Office 自动化时出现的问题

尝试在服务器端解决方案中使用 Office 的开发人员需要了解 Office 的表现因环境而与预期不同的五个主要问题。要成功运行您的代码，就需要解决这些问题，而且需要尽可能减少它们的影响。您在构建应用程序时，要仔细考虑这些问题，因为没有任何一种解决方案能解决所有这些问题，不同的设计要求您优先考虑不同的元素。

用户身份：Office 应用程序在运行时会假定存在一个用户身份，即使在它们由“自动化”启动时也是如此。它们尝试根据用户注册表配置单元中的设置为启动应用程序的用户初始化工具栏、菜单、选项、打印机和一些加载项。许多服务会在没有用户配置文件的帐户（例如，SYSTEM 或 IWAM_[servername] 帐户）下运行，因此，Office 可能无法在启动时进行正确的初始化，进而返回一个有关“CreateObject”或“CoCreateInstance”的错误。即使能够在没有用户配置文件的情况下启动 Office 应用程序，其他功能也可能无法正常工作。如果您计划从某个服务进行“Office 自动化”，需要配置您的代码或 Office，以便它使用某个已加载的用户配置文件来运行。

与桌面的交互性：Office 应用程序假定它们在某个交互式桌面下运行，在有些情况下，可能需要让用户看到它们以便某些“自动化”功能正常运行。如果发生意外错误，或者需要一个未指定的参数才能完成某项功能，根据设计，Office 会用一个模式对话框提示用户，询问用户要进行什么操作。非交互式桌面上的模式对话框是无法取消的，这就导致该线程无限期地停止响应（挂起）。虽然有些代码编写的经验做法有助于减少发生这种情况的可能性，但还是无法做到完全防止。正是这种情况使得从服务器端环境运行 Office 应用程序带有风险，而且不受支持。

重入和可伸缩性：服务器端组件需要是具有较高可重入性的多线程 COM 组件，这些组件在有多个客户端时开销最少而吞吐量较高。Office 应用程序在几乎所有方面都正好相反。它们是非重入的、基于 STA 的“自动化”服务器，是为给一个客户端提供多种多样但占用资源较多的功能而设计的。它们作为服务器端解决方案提供不了多少可伸缩性，而且对于重要元素有固定的限制，例如，对于内存，无法通过配置进行更改。更重要的是，它们要使用全局性资源（例如，映射到内存的文件、全局加载项或模板，以及共享的“自动化”服务器），这样可能会限制能够并发运行的实例的数量，而且，如果它们是在多客户端环境中配置的，还可能导致争用的情况。开发人员如果计划同时运行多个任意“Office 应用程序”的实例，就需要考虑“后台处理”或序列化对“Office 应用程序”的访问，以避免可能出现的死锁或数据损坏。

复原性和稳定性：Office 2000、Office XP 和 Office 2003 使用 Microsoft Windows 安装程序 (MSI) 技术，以使最终用户在进行安装和自行修复时更加容易。MSI 推出了“首次使用时安装”的概念，允许在运行时动态安装或配置功能（针对系统，或者更多地针对特定用户）。在服务器端环境中，这会既降低性能，又增加出现要求用户同意安装或提供相应安装盘的对话框的可能性。虽然此设计旨在增强 Office 作为最终用户产品的复原性，但 Office 实现 MSI 功能在服务器端环境中还是会对生产力带来不利影响。此外，在服务器端运行时，Office 的稳定性通常无法得到保障，因为它尚未为这样使用而进行设计或测试。在网络服务器上使用 Office 作为服务组件可能会降低这台计算机的稳定性，进而降低您的网络作为一个整体的稳定性。如果您计划在服务器端自动运行 Office，请尝试将该程序隔离到一台专用计算机上，该计算机不能影响重要功能，而且在需要时可以重新启动。

服务器端安全性：Office 应用程序从来都不是为在服务器端使用而准备的，因此，请不要考虑分布式组件所面临的安全性问题。Office 不对传入的请求进行身份验证，而且不会保护您免受无意中从服务器端代码中运行宏或启动另一台可能会运行宏的服务器的损害。不要打开从匿名网站上载到服务器上的文件！基于上一次设置的安全性设置，服务器可能会在具有全部特权的 Administrator 或 System 上下文下运行宏，并危及您的网络的安全！另外，Office 使用很多客户端组件（例如，Simple MAPI、WinInet、MSDAIPP），它们会缓存客户端身份验证信息以加快处理速度。如果在服务器端进行 Office 自动化，则一个实例可能为多个客户端提供服务，而且由于已经为该会话缓存了身份验证信息，就有可能出现这样的情况：一个客户端可以使用另一个客户端的缓存凭据，从而通过模拟其他用户获得未经授予的访问权限。

除了要考虑技术问题以外，您还必须考虑这样一种设计在许可方面的可行性。目前的许可原则禁止在服务器上使用“Office 应用程序”为客户端请求提供服务，除非那些客户端自己具有 Office 的许可副本。《最终用户许可协议》(EULA) 没有涉及使用服务器端“自动化”向未经许可的工作站提供 Office 功能的情况。

参考:http://support.microsoft.com/kb/257757

 

   但是按模板生成word/excel是一个很频繁的需求,这个功能非常常用,又实用.暂时也没时间找替代方案,只好找办法解决权限问题.

继续Google,发现可以通过DCOM配置的方式.其做法都是将DCOM配置中的Excel运行账户添加到安全选项卡下的"启动和激活","访问","配置"中.

参考:

http://www.cnblogs.com/qxw0816/archive/2011/05/26/2058986.html

http://blog.csdn.net/qq283718380/article/details/7243072

 

这里将为IIS App Pool配置的运行账户提交到这3个选项中.

PS:发现权限中没有管理组的账号,导致一个问题,asp.net能正常运行excel,但是直接在左面上无法打开,报错"无法嵌入对象".

安全介绍:

项目     详细信息

启动和激活权限

单击以下选项按钮之一：

使用默认值：单击此按钮以指定应用程序使用在计算机属性页的“COM 安全”选项卡上设置的默认权限。

自定义：单击此按钮以指定应用程序使用您设置的权限。若要更改权限，请单击“编辑”。

访问权限

单击以下选项按钮之一：

使用默认值：单击此按钮以指定应用程序使用在计算机属性页面的“COM 安全”选项卡上设置的默认权限。

自定义：单击此按钮以指定应用程序使用您设置的权限。若要更改权限，请单击“编辑”。

配置权限

单击以下选项按钮之一：

使用默认值：单击此按钮以指定应用程序使用默认的注册表配置权限。

自定义：单击此按钮以指定应用程序使用您设置的注册表配置权限。若要更改权限，请单击“编辑”。

参考:http://technet.microsoft.com/zh-cn/library/dd183820.aspx

 

在标识中"交互式","启动","特定"到底应该怎样选择呢?其实通过MS的文档,可以很容易理解.

asp.net启动的情况,适合于"启动用户".

PS:注意安全策略.

 

标识介绍:

“交互式用户”选项按钮

单击以指定应用程序在当前已登录该计算机的用户身份下运行。对应用程序进行身份验证以访问资源时将使用此用户的安全凭据。

“启动用户”选项按钮

单击以指定应用程序使用已启动该应用程序的用户（启动用户）的安全上下文运行，以便可以在域中对该应用程序进行身份验证。启动用户可以是交互式用户。

“下列用户”选项按钮

单击以指定应用程序使用指定用户帐户的安全上下文运行，以便可以在域中对该应用程序进行身份验证。键入用户名和密码。

“系统帐户”选项按钮

单击以指定服务器应用程序使用内置系统帐户的安全上下文运行。此选项仅对作为服务安装的应用程序可用。

参考:http://technet.microsoft.com/zh-cn/library/dd145632.aspx