HTTP Object Request e processamento de solicitações locais

Question

Eu tenho uma aplicação web que usa o objeto CDO Mensagem para relatórios de e-mail.

Por exemplo:

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

O problema é que, quando se faz a sua solicitação para IIS, ele não herda a identidade da sessão ASP do usuário conectado ou seja, as variáveis ??de sessão usados ??para solicitações autenticação antes de permitir o acesso ao conteúdo estão em branco. Isso faz com que a autenticação forte, obrigando-me a adicionar uma variável querystring (porque como você pode ver, você não pode adicionar uma variável de forma a este pedido) como:

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

Com certeza deve haver uma forma de autorização no relatório para verificar se o pedido veio da máquina local ou seja, o objeto CDO no script mailer, negando assim a necessidade de autenticação?

Answer 1

Apenas não faça isso! Por estas razões: -

• Fazer um segundo pedido de volta para o servidor fará com que o segmento atual bloco, se você tem muitos desses você vai impasse da aplicação.
• CreateHTMLBody usa internamente o WinINET http pilha para fazer a solicitação. Essa pilha é destinado para uso em clientes cenários interativos. No cenário de servidor não é thread-safe.
• Você perde todo o contexto da sessão para que ele possa (como você estão descobrindo) Faz algumas coisas mais difíceis ou menos seguro. Além disso, pode criar uma carga de sessões indesejados.

Enquanto seu verdadeiro CreateHTMLBody pode ser muito conveniente serviço também pode criar e-mails inchado. Na situação do servidor que você realmente precisa para criar o e-mail com o código ao invés de uso deste método tentador.

Editar

Parece Jimbo tem cenários mais gerais em mente que apenas CreateHTMLBody. O cenário geral é que um componente (sobre o qual o consumidor não tem controle) é usado em uma página ASP (vamos designar este o "Client Page") e faz um pedido posterior (potencialmente via WinINET) para outra página ASP (nós vai designar este o "Serviço Página"). Existe a hipótese de que a única coisa que a "página do cliente" pode controlar sobre o uso do componente é o URL fornecido a ele.

Aqui estão algumas abordagens para evitar ou mitigar os problemas descritos acima.

Manipulação Locking Problemas: Colocar o "Client Page" e "Página de Serviço" na aplicação ASP diferente evitaria os problemas de bloqueio. Minha sugestão seria colocar o "Client Page" em uma aplicação diferente para o resto da aplicação e que esta nova aplicação seria na sub pasta da aplicação principal.

Lidar com WinINET questões: Coloque o novo aplicativo em seu próprio pool de aplicativos. Se estiver usando WinINET de forma insegura causa um problema que não afecta o processo principal do aplicativo. colocando-o fato em seu próprio processo pode ajudar a evitar tais problemas. (Há garantias aqui, mas é o melhor que você pode começar a evitar WinINET questões completamente).

Controle de segurança: Configurar o "Serviço Página" para aceitar apenas pedidos do "página do cliente". Há provavelmente um número de maneiras de fazer isso, mas a mais simples é permitir segurança baseada em IP, os pedidos para o "Serviço de Página" só deve ser proveniente de um determinado IP ou pelo menos um conjunto limitado de endereços IP.

autenticação de manipulação: Durante a aplicação principal de logon criar um cookie volátil contendo algum valor único. Desde o "Client Page" é percebida como uma sub-pasta da aplicação principal do navegador que irá receber esse cookie. O "Client Page" pode usar esse cookie para confirmar a autenticidade do pedido e / ou passá-lo na URL quando utilizando o componente.

Supressing criação sessão prolífico:. Ter o "Serviço de Página" chamada Session.Abandon antes de concluir sua operação