HTTP要求オブジェクトとローカル要求の処理

Question

CDO Messageオブジェクトを使用してレポートをメールで送信するWebアプリケーションがあります。

例：

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

問題は、IISにリクエストを送信すると、ログインしているユーザーのASPセッションIDを継承しないことです。つまり、コンテンツへのアクセスを許可する前にリクエストを認証するために使用されるセッション変数が空白です。これにより認証が難しくなり、次のようにクエリ文字列変数を追加せざるを得なくなります（ご覧のとおり、このリクエストにフォーム変数を追加することはできません）。

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

確かに、リクエストがローカルマシン、つまりメーラースクリプトのCDOオブジェクトから来たかどうかを確認するために、レポートに承認の方法がなければならないので、認証の必要性を否定しますか？

Answer 1

やらないでください！これらの理由により：-

• 2番目の要求をサーバーに戻すと、現在のスレッドがブロックされます。これらの要求が多すぎると、アプリケーションがデッドロックします。
• CreateHTMLBody は内部的にWinINET httpスタックを使用してリクエストを作成します。このスタックは、クライアントのインタラクティブなシナリオで使用するためのものです。サーバーシナリオでは、スレッドセーフではありません。
• すべてのセッションコンテキストが失われるため、（発見中に）何かをより困難にしたり、安全性を低くしたりできます。さらに、不要なセッションが大量に発生する可能性があります。

真の CreateHTMLBody は非常に便利ですが、肥大化したメールを作成することもできます。サーバーの状況では、この魅力的な方法を使用するのではなく、コードでメールを作成する必要があります。

編集

Jimboには、単にCreateHTMLBodyよりも一般的なシナリオがあります。一般的なシナリオは、コンポーネント（消費者が制御できない）がASPページで使用され（これを「クライアントページ」と指定します）、別のASPページに後続の要求（WinINETを介して）を行います（これを「サービスページ」と指定します）。 「クライアントページ」が唯一のものであるという仮定があります。コンポーネントの使用状況を制御できるのは、コンポーネントに提供されるURLです。

上記の問題を回避または軽減するためのアプローチを次に示します。

ロックの問題の処理：＆quot;クライアントページ＆quot;および「サービスページ」別のASPアプリケーションでは、ロックの問題を回避できます。私の提案は、「クライアントページ」を配置することです。他のアプリケーションとは別のアプリケーションで、この新しいアプリケーションがメインアプリケーションのサブフォルダーにあること。

WinINETの問題への対処：新しいアプリケーションを独自のアプリケーションプールに配置します。安全でない方法でWinINETを使用しても問題が発生する場合、メインアプリケーションプロセスには影響しません。実際、それを独自のプロセスに配置すると、このような問題を回避できる場合があります。 （ここでは保証はありませんが、WinINETの問題を完全に回避するには最善です）。

セキュリティの制御：「サービスページ」を設定します。 ＆quot;クライアントページ＆quot;からのリクエストのみを受け入れます。これを行うにはおそらくいくつかの方法がありますが、最も簡単なのは、IPベースのセキュリティを有効にすることです。特定のIPまたは少なくとも限られたIPアドレスのセットからのみ来ている必要があります。

認証の処理：メインアプリケーションのログオン中に、一意の値を含む揮発性Cookieを作成します。 「クライアントページ」以来、このCookieを受信するブラウザーは、メインアプリケーションのサブフォルダーとして認識されます。 「クライアントページ」このCookieを使用して、リクエストの信頼性を確認したり、コンポーネントの使用時にURLで渡したりできます。

多作のセッション作成の抑制：＆quot;サービスページ＆quot;操作を完了する前に Session.Abandon を呼び出します。