IIS Metabase GetObject调用返回错误424对象所需错误

IIS元数据不是为了安全，而仅仅是为了方便。 它只是几个虚拟服务器（IIS / ASP应用程序）共享数据的中央存储库。因此，如果仅出于安全目的使用它，则根本不需要Metabase。 因为： 你是谁“隐藏我们的数据库访问细节”？程序员？但他已经获得了它。将

ConfigKey.Get("ODBCPassword")

分配给密码后，任何

response.write

都会显示出来。即使这是在

global.asa

中完成的，在某处您必须将其转换为连接字符串（或将其存储在

Application

变量中），因此

.asp

页面可以创建数据库连接对象。在Metabase和对象创建之间的某个时刻，他将可以访问连接属性。 甚至不考虑通过在

global.asa

创建连接对象并将对象本身存储在Application变量中来防止这种情况。 （从而将创建隐藏在程序员可访问的文件中）。这不仅会杀死连接池，还会带来巨大的负面性能损失。 如果您担心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文件中。 那就是说，我不是说Metabase没用。它仍然是一个存储数据的好方便的地方，因为： 无需更改任何代码行即可更改数据 有几个网站可以共享数据，即使每个网站都有自己独立的应用程序 集中数据总是比保持配置和包含分散在整个文件系统中的文件更容易保持 用户/ NTFS许可证的设置方式只允许授权人员更改数据，但网站用户（和ASP开发人员）只能读取它 也就是说，“有限的数据库用户”+“COM类连接包装器”是大多数公司使用的方法。当然，关注安全的人。其他人只使用“global.asa中硬编码的连接字符串，然后存储在应用程序变量中”。