Objet de requête HTTP et traitement des requêtes locales

Question

J'ai une application Web qui utilise l'objet Message CDO pour envoyer des rapports par courrier électronique.

Par exemple:

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

Le problème est que, lorsqu'il adresse sa demande à IIS, il n'hérite pas de l'identité de session ASP de l'utilisateur connecté, c'est-à-dire que les variables de session utilisées pour authentifier les demandes avant d'autoriser l'accès au contenu sont vides. Cela rend l’authentification difficile, me forçant à ajouter une variable de chaîne de requête (car, comme vous pouvez le constater, vous ne pouvez pas ajouter de variable de formulaire à cette demande) comme:

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

SÛREMENT, il doit exister un moyen d’autorisation dans le rapport pour vérifier si la demande provient de la machine locale, c’est-à-dire de l’objet CDO dans le script de messagerie, éliminant ainsi le besoin d’authentification?

Answer 1

Ne le faites pas! Pour ces raisons: -

• Faire une deuxième requête sur le serveur provoque le blocage du thread actuel. Si vous en avez trop, vous bloquez l'application.
• CreateHTMLBody utilise en interne la pile http WinINET pour effectuer la demande. Cette pile est destinée à être utilisée dans des scénarios interactifs client. Dans le scénario du serveur, il n’est pas thread-safe.
• Vous perdez tout le contexte de la session, ce qui peut (comme vous le découvrez) rendre certaines choses plus difficiles ou moins sécurisées. En outre, il peut créer un chargement de sessions indésirables.

Bien que son véritable CreateHTMLBody puisse être très pratique, il peut également créer des courriels volumineux. Au niveau du serveur, vous devez vraiment créer l’email avec du code plutôt que d’utiliser cette méthode séduisante.

Modifier

Il semble que Jimbo envisage des scénarios plus généraux que juste CreateHTMLBody. Le scénario général est qu'un composant (sur lequel le consommateur n'a aucun contrôle) est utilisé dans une page ASP (nous le désignerons comme "page client") et qu'il émettra une requête ultérieure (potentiellement via WinINET) vers une autre page ASP ( nous désignerons cela la "page de service"). Il y a l'hypothèse que la seule chose que la " Page du client " peut contrôler l'utilisation du composant à l'aide de l'URL fournie.

Voici quelques approches pour éviter ou atténuer les problèmes décrits ci-dessus.

Gestion des problèmes de verrouillage: Placement de la "page client" " et la "page de service". dans différentes applications ASP éviterait les problèmes de verrouillage. Ma suggestion serait de placer la "page client" " dans une application différente du reste de l'application et que cette nouvelle application serait dans le sous-dossier de l'application principale.

Traitement des problèmes WinINET: Placez la nouvelle application dans son propre pool d'applications. Si utiliser WinINET de manière non sécurisée pose un problème, cela n’affecte pas le processus principal de l’application. En effet, le placer dans son propre processus peut aider à éviter de tels problèmes. (Aucune garantie ici, mais c’est le meilleur moyen d’éviter complètement les problèmes WinINET).

Contrôle de la sécurité: configurer la " page de service " accepter uniquement les demandes de la "page client". Il existe probablement plusieurs façons de procéder, mais la plus simple consiste à activer la sécurité sur IP, les requêtes adressées à la "page de service". ne devrait provenir que d'une adresse IP spécifique ou d'au moins un ensemble limité d'adresses IP.

Gestion de l'authentification: Lors de la connexion de l'application principale, créez un cookie volatile contenant une valeur unique. Depuis la "page client" " est perçu comme un sous-dossier de l'application principale par le navigateur, il recevra ce cookie. La " page client " peut utiliser ce cookie pour confirmer l’authenticité de la demande et / ou la transmettre à l’URL lors de l’utilisation du composant.

Suppression de la création de session prolifique: créer la "page de service" " appelez Session.Abandon avant la fin de son opération.