1

我有一个使用 CDO Message 对象通过电子邮件发送报告的 Web 应用程序。

例如：

Dim objCDO
Set objCDO = Server.CreateObject("CDO.Message")
objCDO.CreateMHTMLBody "http://server/report.asp"

问题是当它向 IIS 发出请求时，它没有继承登录用户的 ASP 会话标识，即在允许访问内容之前用于验证请求的会话变量是空白的。这使得身份验证变得困难，迫使我添加一个查询字符串变量（因为如您所见，您不能向此请求添加表单变量），例如：

objCDO.CreateMHTMLBody "http://server/report.asp?userid=xx&password=xx"

肯定在报告中必须有一种授权方式来检查请求是否来自本地机器，即邮件脚本中的 CDO 对象，从而否定身份验证的需要？

4

1 回答 1

2

只是不要这样做！由于这些原因：-

  • 向服务器发出第二个请求将导致当前线程阻塞，如果您有太多这些请求，您将死锁应用程序。
  • CreateHTMLBodyinternaly 使用 WinINET http 堆栈来发出请求。此堆栈旨在用于客户端交互场景。在服务器场景中，它不是线程安全的。
  • 您丢失了所有会话上下文，因此它可以（正如您所发现的那样）使某些事情变得更困难或更不安全。此外，它还可以创建大量不需要的会话。

虽然它的真实性CreateHTMLBody可以非常方便，但它也可以创建臃肿的电子邮件。在服务器情况下，您确实需要使用代码编写电子邮件，而不是使用这种诱人的方法。

编辑

似乎 Jimbo 考虑的不仅仅是 CreateHTMLBody 更一般的场景。一般情况是，一个组件（消费者无法控制）在一个 ASP 页面（我们将其指定为“客户端页面”）中使用，并且它向另一个 ASP 页面（我们将其指定为“服务页面”）。假设“客户端页面”可以控制组件使用的唯一事情是提供给它的 URL。

以下是一些避免或减轻上述问题的方法。

处理锁定问题：将“客户端页面”和“服务页面”放在不同的 ASP 应用程序中可以避免锁定问题。我的建议是将“客户端页面”放在与应用程序的其余部分不同的应用程序中，并且这个新应用程序将位于主应用程序的子文件夹中。

处理 WinINET 问题：将新应用程序放在它自己的应用程序池中。如果以不安全的方式使用 WinINET 确实会导致问题，它不会影响主应用程序进程。事实上，将其置于自己的进程中可能有助于避免此类问题。（这里不能保证，但它是完全避免 WinINET 问题的最佳方法）。

控制安全性：将“服务页面”配置为仅接受来自“客户端页面”的请求。可能有很多方法可以做到这一点，但最简单的是启用基于 IP 的安全性，对“服务页面”的请求只能来自特定 IP 或至少一组有限的 IP 地址。

处理身份验证： 在主应用程序登录期间，创建一个包含一些唯一值的易失性 cookie。由于“客户端页面”被浏览器视为主应用程序的子文件夹，因此它将接收此 cookie。“客户端页面”可以使用此 cookie 来确认请求的真实性和/或在使用组件时将其传递到 URL 中。

抑制多产的会话创建：Session.Abandon在完成操作之前调用“服务页面” 。

于 2009-10-23T09:16:52.643 回答