Objeto de solicitud HTTP y procesamiento de solicitudes locales

Question

Tengo una aplicación web que utiliza el objeto Mensaje de CDO para enviar informes por correo electrónico.

Por ejemplo:

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

El problema es que cuando realiza su solicitud a IIS, no hereda la identidad de sesión ASP del usuario que ha iniciado sesión, es decir, las variables de sesión utilizadas para autenticar solicitudes antes de permitir el acceso al contenido están en blanco. Esto hace que la autenticación sea difícil, lo que me obliga a agregar una variable de cadena de consulta (porque, como puede ver, no puede agregar una variable de formulario a esta solicitud) como:

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

Seguramente debe haber una forma de autorización en el informe para verificar si la solicitud proviene de la máquina local, es decir, el objeto CDO en el script del remitente, lo que niega la necesidad de autenticación.

Answer 1

¡No lo hagas! Por estas razones: -

• Si vuelve a hacer una segunda solicitud al servidor, se bloqueará el subproceso actual. Si tiene demasiados, bloqueará la aplicación.
• CreateHTMLBody usa internamente la pila http de WinINET para realizar la solicitud. Esta pila está diseñada para su uso en escenarios interactivos de clientes. En el escenario del servidor, no es seguro para subprocesos.
• Se pierde todo el contexto de la sesión para que pueda (a medida que lo descubra) hacer que algunas cosas sean más difíciles o menos seguras. Además, puede crear una carga de sesiones no deseadas.

Si bien su verdadero CreateHTMLBody puede ser muy conveniente, también puede crear correos electrónicos inflados. En la situación del servidor, realmente necesita elaborar el correo electrónico con un código en lugar de utilizar este método tentador.

Editar

Parece que Jimbo tiene más escenarios generales en mente que solo CreateHTMLBody. El escenario general es que un componente (sobre el cual el consumidor no tiene control) se usa en una página ASP (lo designaremos como "Página de cliente") y realiza una solicitud posterior (potencialmente a través de WinINET) a otra página ASP ( Designaremos esto en la " Página de servicio "). Se supone que lo único que " Página del cliente " El control sobre el uso del componente es la URL que se le proporciona.

Aquí hay algunos enfoques para evitar o mitigar los problemas descritos anteriormente.

Manejo de problemas de bloqueo: colocando la " Página del cliente " y la " Página de servicio " En diferentes aplicaciones de ASP se evitarían los problemas de bloqueo. Mi sugerencia sería colocar la " Página del cliente " en una aplicación diferente al resto de la aplicación y que esta nueva aplicación estaría en la subcarpeta de la aplicación principal.

Cómo lidiar con los problemas de WinINET: coloque la nueva aplicación en su propio grupo de aplicaciones. Si usar WinINET de una manera insegura causa un problema, no afecta el proceso principal de la aplicación. De hecho, colocarlo en su propio proceso puede ayudar a evitar tales problemas. (No hay garantías aquí, pero es lo mejor que puede hacer para evitar por completo los problemas de WinINET).

Control de seguridad: configurar la " Página de servicio " para aceptar solo solicitudes de la " Página del cliente " ;. Probablemente hay varias formas de hacerlo, pero la más sencilla es habilitar la seguridad basada en IP, las solicitudes a la " Página de servicio " solo debe provenir de una IP específica o al menos un conjunto limitado de direcciones IP.

Manejo de la autenticación: durante el inicio de sesión de la aplicación principal, cree una cookie volátil que contenga algún valor único. Desde la " Página del cliente " Se percibe como una subcarpeta de la aplicación principal por el navegador que recibirá esta cookie. La " Página del cliente " puede usar esta cookie para confirmar la autenticidad de la solicitud y / o pasarla a la URL cuando use el componente.

Suprimir la prolífica creación de sesiones: tener la " Página de servicio " llame a Session.Abandon antes de que complete su operación.