HTTP Request-Objekt und Verarbeitung von lokalen Anfragen

Question

Ich habe eine Web-Anwendung, die das CDO-Message-Objekt verwendet Berichte per E-Mail.

Zum Beispiel:

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

Das Problem ist, dass, wenn er seine Anforderung an IIS macht, ist es nicht die ASP-Sitzung Identität der Anfragen verwendet in Benutzer das heißt die Session-Variablen angemeldet erben zu authentifizieren, bevor leer sind Zugriff auf den Inhalt zulässt. Dies macht die Authentifizierung hart und zwingt mich eine Abfragezeichenfolgeflag Variable hinzuzufügen (weil, wie Sie sehen können, können Sie eine Formularvariable auf diese Anforderung hinzufügen kippe) wie:

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

Es muss doch eine Möglichkeit, von der Ermächtigung in dem Bericht, zu prüfen, ob die Anforderung von der lokalen Maschine heißt das CDO-Objekt in der Mailer Skript kam, wodurch die Notwendigkeit für die Authentifizierung zu negieren?

Answer 1

Nur nicht tun Sie es! Aus diesen Gründen: -

• eine zweite Anforderung wieder in den Server zu machen wird der aktuelle Thread führen zu blockieren, wenn Sie diese zu viele haben Sie die Anwendung Deadlock.
• CreateHTMLBody internaly verwendet den WinINET HTTP-Stack, um die Anforderung zu machen. Dieser Stack ist für den Einsatz in Client interaktiven Szenarien gedacht. Im Server-Szenario ist es nicht Thread-sicher.
• Sie verlieren alle Session-Kontext, so dass es (wie Sie zu entdecken sind) Somethings schwieriger oder weniger sicher machen. Darüber hinaus kann es eine Last von unerwünschten Sitzungen erstellen.

Während seine wahren CreateHTMLBody kann sehr praktisch sein, kann es auch aufgebläht E-Mails erstellen. In der Server-Situation die Sie wirklich brauchen die E-Mail mit dem Code zu fertigen, anstatt diese verlockende Methode zu verwenden.

Bearbeiten

Es scheint, Jimbo allgemeinere Szenarien im Sinn hat, als nur CreateHTMLBody. Das allgemeine Szenario ist, dass eine Komponente (über die der Verbraucher hat keine Kontrolle) in einer ASP-Seite verwendet wird (wir dies die „Client-Seite“ bezeichnen wird) und es macht einen späteren Antrag (möglicherweise über WinINET) zu einer anderen ASP-Seite (wir dies die „Service Page“) benennt. Es besteht die Annahme, dass das einzige, was die „Client-Seite“ über die Verwendung der Komponente steuern kann die URL, um es zugeführt wird.

Hier sind einige Ansätze, um die oben erläuterten Faktoren zu vermeiden oder zu mildern.

Handhabung Locking Probleme: Platzieren die "Client-Seite" und die "Service-Seite" in verschiedener ASP-Anwendung würde die Probleme mit Sperren vermeiden. Mein Vorschlag wäre die „Client-Seite“ wird in einer anderen Anwendung auf den Rest der Anwendung und dass diese neue Anwendung in Unterverzeichnis der Hauptanwendung sein würde.

Der Umgang mit WinINET Themen: Legen Sie die neue Anwendung in einem eigenen Anwendungspool. Bei der Verwendung von WinINET auf unsichere Art und Weise ein Problem verursacht, ist es nicht das Hauptanwendungsprozess beeinflussen. Platzierung es in der Tat in einem eigenen Prozess helfen, solche Probleme vermeiden kann. (Keine Garantien hier aber es ist das Beste, was Sie WinINET Probleme zu vermeiden vollständig erhalten können).

Controlling Sicherheit: Konfigurieren Sie die "Service Page", um nur Anfragen aus der "Client-Seite" übernehmen. Es gibt wahrscheinlich eine Reihe von Möglichkeiten, dies zu tun, aber die einfachste ist IP-basierte Sicherheit zu ermöglichen, die Anforderungen an der „Service-Seite“ sollen nur von einer bestimmten IP oder zumindest eine begrenzte Anzahl von IP-Adressen kommen werden.

Handling-Authentifizierung: Während die Hauptanwendung der Anmeldung erstellen ein flüchtiges Cookie einigen einzigartigen Wert enthält. Da die „Client-Seite“ als Unterordner der Hauptanwendung durch den Browser wahrgenommen wird, wird es dieses Cookie erhalten. Die „Client-Seite“ dieses Cookies kann die Echtheit der Anfrage und / oder sie in der URL zu bestätigen, wenn die Komponente verwendet wird.

Unterdrücken produktivsten Sitzung Schöpfung: , um den "Service-Seite" Anruf Session.Abandon hat, bevor es vollendet seinen Betrieb

.