HTTP请求对象和处理本地请求

时间:2009-10-23 07:47:21

标签: iis asp-classic httprequest cdo.message

我有一个使用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"

SURELY报告中必须有一种授权方式来检查请求是否来自本地机器,即邮件脚本中的CDO对象,从而无需验证?

1 个答案:

答案 0 :(得分:2)

就是不要这样做!出于这些原因: -

  • 将第二个请求发回服务器会导致当前线程被阻塞,如果你有太多这样的请求会使应用程序死锁。
  • CreateHTMLBody internaly使用WinINET http堆栈发出请求。此堆栈旨在用于客户端交互方案。在服务器方案中,它不是线程安全的。
  • 您丢失了所有会话上下文,因此它可以(正如您所发现的那样)使某些事情更难或更不安全。此外,它还会产生大量不需要的会话。

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

修改

看起来Jimbo的心态比CreateHTMLBody更多。一般情况是在ASP页面中使用一个组件(消费者没有控制权)(我们将其指定为“客户端页面”)并且它将后续请求(可能通过WinINET)发送到另一个ASP页面(我们将指定这个“服务页面”)。假设“客户页面”可以控制组件使用的唯一内容是提供给它的URL。

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

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

处理WinINET问题:将新应用程序放在自己的应用程序池中。如果以不安全的方式使用WinINET会导致问题,它不会影响主应用程序进程。确实将其置于自己的过程中可能有助于避免此类问题。 (这里没有保证,但你可以完全避免WinINET问题)。

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

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

禁止多产会话创建:“服务页面”在完成其操作之前调用Session.Abandon