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