IIS元數據庫GetObject調用返回錯誤424對象所需的錯誤

Question

我們有一個運行在Windows Server 2003和IIS6上的ASP經典網站，它正在拋出間歇性的運行時錯誤424對象。我們跟蹤下來到初始化對象引用到元數據庫中的線如下圖所示（第二行）：

MetaBasePath="IIS://" & ComputerName & "/" & StorageKey & "/" & DataAccessKey 
Set ConfigKey=GetObject(MetaBasePath) 
DataSource=ConfigKey.Get("ODBCDataSource") 
UserName=ConfigKey.Get("ODBCUserName") 
Password=ConfigKey.Get("ODBCPassword") 

我搜索計算器（和一般的網絡），其他任何人的任何跡象有這個問題，但畫了一個空白。有沒有人有任何想法可能導致這種情況？是否有任何性能相關的設置來控制訪問元數據庫的頻率？我們可以採用哪些最佳實踐措施來提高Metabase訪問的效率？我們是否正確地假設我們通過隱藏Metabase中的數據庫訪問詳細信息來做正確的事情，或者從安全角度來看這是否過分了？

此問題影響我們約1％的頁面點擊率。

我們正在研究一系列操作，包括檢查服務器軟件組件的修補程序級別，並且可能在上述代碼周圍添加一個循環以繼續嘗試，直到Metabase對象被正確初始化，但這最多隻是一個短期修復我的意見。

建議最受歡迎！感謝， 克雷格。

附加信息：剛剛發現啓用了IIS5.0隔離模式。我試圖找出爲什麼這是啓用，但這可能是相關的？

Answer 1

IIS元數據庫不是爲了安全，而僅僅是爲了方便。

它只是一箇中央數據庫，由多個虛擬服務器（IIS/ASP應用程序）共享數據。因此，如果僅僅出於安全目的而使用它，那麼Metabase是完全不需要的。

因爲：

• 你是誰 「躲在我們的數據庫訪問的細節」 的呢？程序員？但他已經可以訪問它了。在分配密碼ConfigKey.Get("ODBCPassword")後，任何response.write都會顯示它。即使這是在global.asa中完成的，在某處您必須將其轉換爲連接字符串（或將其存儲在Application變量中），因此.asp頁面可以創建數據庫連接對象。在Metabase和對象創建之間的某個點，他將有權訪問連接屬性。

• 甚至不認爲關於由在global.asa創建連接對象和存儲所述對象本身在應用程序中的變量防止這種。 （從而隱藏程序員可訪問文件的創建）。不僅這殺死連接池，而且它的巨大的負面表現打擊。

如果您擔心從ASP網頁數據庫的安全，這裏有一些方法，我建議：

• 創建網站訪問不同的數據庫用戶，以非常有限的權限的。含義SELECT，INSERT，UPDATE，DELETE和EXECUTE（存儲過程）只有。沒有DROP，CREATE，ALTER等等。這樣，任何「密碼泄露」或「程序員濫用」都不會嚴重危害數據庫。具有完整權限的「admin」用戶密碼永遠不會在網站的任何地方訪問（或使用）。

• 創建一個ActiveX（或COM，DCOM）DLL來包裝連接設置。它可以寫在C＃，VB.NET甚至經典的VB6中。它會從另一個（安全和web-innacessible）服務器文件讀取登錄名和密碼，創建連接對象，並直接將其傳遞給ASP。

因此，而不是使用：

set objConn = Server.CreateObject("ADODB.Connection") 

的ASP頁面將使用：

set objConn = Server.CreateObject("MYCLASS.Connection") 

配置文件本身甚至可以被加密，因爲decripit算法將被存儲在編譯代碼，而不是在純文本ASP文件中。

這就是說，我不是說元數據庫是無用的。它仍然是一個不錯的，方便的地方來存儲數據，這是因爲：

• 數據可以在不改變任何一行代碼

• 一些網站可以共享數據被改變，即使每個有它自己獨立的應用程序

• 集中的數據總是更容易十個分量不是保持配置，包括散落在文件系統

• 用戶/ NTFS permititions可以在某種程度上成立，只有AUT文件horized人可以更改數據，但網站用戶（以及ASP開發人員）只能讀取它

這就是說，「有限的數據庫用戶」 +「COM類連接包裝」是在大多數公司香港專業教育學院所使用的方法與之合作。當然，那些關心安全的人。其他人只是使用「在global.asa中硬編碼的連接字符串，然後存儲在應用程序變量中」。