HTTP Request Object и обработка локальных запросов - PullRequest
Новая
       23

HTTP Request Object и обработка локальных запросов

1 голос
/ 23 октября 2009

У меня есть веб-приложение, которое использует объект сообщения CDO для отправки отчетов по электронной почте.

Например: 

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

Проблема заключается в том, что когда он делает свой запрос к IIS, он не наследует идентификатор сеанса ASP вошедшего в систему пользователя, то есть переменные сеанса, используемые для проверки подлинности запросов перед разрешением доступа к контенту, являются пустыми. Это усложняет аутентификацию, заставляя меня добавить переменную строки запроса (потому что, как вы можете видеть, вы не можете добавить переменную формы в этот запрос), например: 

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

ОБЯЗАТЕЛЬНО в отчете должен быть способ авторизации для проверки того, поступил ли запрос с локальной машины, т. Е. Объект CDO в сценарии почтовой программы, что исключает необходимость аутентификации?

1 Ответ

2 голосов
/ 23 октября 2009

Только не делай этого! По этим причинам: -

  • Выполнение второго запроса обратно на сервер приведет к блокировке текущего потока, если у вас их слишком много, вы заблокируете приложение.
  • CreateHTMLBody внутренне использует стек WinINET http для выполнения запроса. Этот стек предназначен для использования в клиентских интерактивных сценариях. В сценарии сервера это не потокобезопасно.
  • Вы теряете весь контекст сеанса, чтобы он мог (как вы обнаруживаете) сделать что-то более трудным или менее безопасным. Кроме того, он может создавать множество нежелательных сессий.

Хотя его истинное значение CreateHTMLBody может быть очень удобным, оно также может создавать раздутые электронные письма. В ситуации с сервером вам действительно нужно создать письмо с кодом, а не использовать этот заманчивый метод.

Редактировать

Кажется, Джимбо имеет в виду более общие сценарии, чем просто CreateHTMLBody. Общий сценарий состоит в том, что компонент (над которым потребитель не имеет никакого контроля) используется на странице ASP (мы обозначим это «Страница клиента»), и он делает последующий запрос (возможно, через WinINET) на другую страницу ASP (мы обозначит это как «Сервисная страница»). Существует предположение, что «страница клиента» может контролировать использование компонента только с предоставленного ему URL-адреса.

Вот некоторые подходы, чтобы избежать или смягчить проблемы, изложенные выше.

Обработка проблем с блокировкой: Размещение «Клиентской страницы» и «Сервисной страницы» в другом приложении ASP позволит избежать проблем с блокировкой. Моим предложением было бы поместить «Клиентскую страницу» в приложение, отличное от остальной части приложения, и что это новое приложение будет находиться в подпапке основного приложения.

Решение проблем WinINET: Поместите новое приложение в собственный пул приложений. Если использование WinINET небезопасным способом вызывает проблемы, это не влияет на основной процесс приложения. Действительно, размещение его в своем собственном процессе может помочь избежать таких проблем. (Здесь нет никаких гарантий, но это лучшее, что вы можете сделать, чтобы полностью избежать проблем WinINET).

Управление безопасностью: Настройте «Сервисную страницу» так, чтобы принимать запросы только от «Клиентской страницы». Вероятно, есть несколько способов сделать это, но самый простой - включить защиту на основе IP, запросы к «странице службы» должны поступать только с определенного IP-адреса или как минимум с ограниченного набора IP-адресов.

Обработка аутентификации: Во время входа в главное приложение создайте изменчивый файл cookie, содержащий некоторое уникальное значение. Поскольку «Страница клиента» воспринимается браузером как подпапка основного приложения, он получит этот файл cookie. «Страница клиента» может использовать этот файл cookie для подтверждения подлинности запроса и / или передачи его по URL-адресу при использовании компонента.

Подавление плодотворного создания сеанса: Перед вызовом "Service Page" вызвать Session.Abandon, прежде чем он завершит свою работу.

...