HTTP-запрос Объект и обработка локальных запросов

Question

У меня есть веб-приложение, которое использует объект сообщения 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 в сценарии почтовой программы, тем самым отрицая необходимость проверки подлинности?

Answer 1

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

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

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

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

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

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

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

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

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

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

Подавляющее создание сеанса: Перед тем, как завершить операцию, перед вызовом «Сервисная страница» Session.Abandon.