我有一个使用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对象,从而无需验证?
答案 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
。