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

我有一个Web应用程序使用CDO消息对象发送电子邮件报告。HTTP请求对象和处理本地请求

例如：

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对象，从而否定了对身份验证的需求？

来源

2009-10-23 Jimbo

@Jimbo：编辑我的回答以解决您的评论。 – AnthonyWJones 2009-10-24 21:22:24

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

将第二个请求返回到服务器将导致当前线程阻塞，如果您有太多这些请求会导致应用程序死锁。
CreateHTMLBody internaly使用WinINET http堆栈发出请求。该堆栈旨在用于客户端交互式场景。在服务器场景中，它不是线程安全的。
你失去了所有的会话上下文，所以它可以（如你所发现的）使事情变得更加困难或不太安全。此外，它可能会创建一些不需要的会话。

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

编辑

看来金宝心中都有不仅仅是CreateHTMLBody更普遍的情形。一般情况是，一个ASP页面（我们将这个“客户端页面”指定为一个组件（消费者无法控制的组件）），并且它会向另一个ASP页面发送后续请求（可能通过WinINET）将指定这个“服务页面”）。假定“客户端页面”可以控制组件的使用唯一的东西是提供给它的URL。

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

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

处理WinINET问题：将新应用程序放置在其自己的应用程序池中。如果以不安全的方式使用WinINET会造成问题，则不会影响主应用程序进程。事实上，把它放在自己的过程中可能有助于避免这种问题。（在这里没有保证，但它是你可以完全避免WinINET问题的最佳选择）。

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

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

Supressing多产的会话创建：有“服务页面”叫Session.Abandon它完成其操作之前。

来源

2009-10-23 09:16:52 AnthonyWJones

呜......我不知道CreateHTMLBody使用了WinINET堆栈。我通常不会使用XMLHTTP，而是出于同样的原因使用ServerXMLHTTP。 +1 – Kev 2009-10-23 16:04:42

感谢您的回复。不幸的是，这种应用程序有很多例子，使用也使用类似的GetContentFromURL的PDF创建控件 - 这些实例没有替代方案。 – Jimbo 2009-10-24 10:53:07

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

回答

相关问题