Нужны предложения для ASP.Net или IIS Запрос URL Mangling

Среда:

  • Server 2008
  • IIS 7, интегрированный режим
  • .Net 4
  • ASP.NET WebForms Routing (которая использует ту же DLL-библиотеку, что и MVC-маршрутизация, хотя я не уверен, какая версия)
  • Сессии без файлов cookie (идентификатор сессии перемещается по URL-адресу пользователя).

У нас есть приложение, которое использует маршрутизацию, чтобы определить, с какой организацией связан пользователь. URL-адрес будет иметь форму домена /Organization/OrganizationSubCategory. Пользователь переходит на свой пользовательский URL и видит целевую страницу. Когда они нажимают следующее, они направляются на страницу, которая собирает некоторую демографическую информацию, затем они нажимают следующую, чтобы перейти к приложению. Когда они это делают, пользователь добавляется (при необходимости) к их организации в нашей базе данных. После начальной целевой страницы маршрутизация больше не применяется - пользователь перенаправляется на обычные aspx-страницы.

Сайт получает достаточное количество пользователей, заходящих в приложение; в среднем 850 в день.

Проблема в том, что небольшое количество (менее 1%) пользователей добавляются в неправильную организацию.

Мы регистрируем информацию на целевой странице и когда они отправляют демографическую страницу. Одна вещь, которую мы регистрируем - это Request.RawUrl. Мы начали замечать пользователей, которые связаны с одной организацией, которая вошла в систему как запрашивающая полный правильный URL (включая подкатегорию) другой организации. Иногда никто не мог на законных основаниях следовать за неправильным URL организации даже в тот же день. У нас были люди, которые прямо сообщали, что они только что создали "подкатегорию" (используя административное приложение), проинструктировали пользователя следовать его уникальному URL, и все же в журналах показан совершенно другой URL для этого самого пользователя (я знаю, что это пользователя, потому что я регистрирую адрес электронной почты и идентификатор сеанса, чтобы я мог связать путь одного и того же пользователя через целевую страницу и демографическую страницу). Как будто IIS иногда создает новый сеанс и просто назначает некоторый ранее запрошенный URL этому пользователю.

В попытке устранить какое-то кэширование, мы имеем:

  • Установите для атрибута enableKernelOutputCache элемента config httpRuntime значение false
  • Отключено кеширование в настройках IIS
  • Задайте для атрибута refreshrateExpiredSessionId элемента config sessionState значение false (хотя мы не видели повторного использования идентификаторов сеансов).

Другие предложения?

2 ответа

Это внутренние пользователи? Есть ли прокси соображения? Это не объясняет неправильный URL, хотя. Вы на 100% уверены, что пользователям дали URL A, и они появляются с URL b? Есть ли у вас какие-либо модули маршрутизации в настоящее время назначены? Вы уверены, что правило не переписывается в другом модуле?

Может ли это быть проблемой приложения, когда в электронном письме "нового пользователя" (например) указан неверный URL?

Ну, мы все еще не знаем с полной уверенностью, но, похоже, пользователи одной организации, скорее всего, искали в Интернете, чтобы найти URL-адреса в системе и следили за ними.
Я не могу объяснить отчет, который у нас был, как я описал в оригинальном посте.
Когда я попытался улучшить ведение журнала, чтобы захватить создание перед сессией, чтобы доказать это наверняка, регистрация события начала запроса работала в нашей среде QA (так же, как в рабочей среде), но просто не работала в рабочей среде. Я никогда не мог определить, почему.

Другие вопросы по тегам