Нужны предложения для ASP.Net или IIS Запрос URL Mangling - PullRequest
0 голосов
/ 29 сентября 2011

Среда:

  • Сервер 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 httpRunname значение false
  • Отключенное кэширование в настройках IIS
  • Установите для атрибутаgenraterateExpiredSessionId элемента config значение false (даже если мы не видели, чтобы идентификаторы сессии использовались повторно).

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

Ответы [ 2 ]

0 голосов
/ 20 октября 2011

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

0 голосов
/ 29 сентября 2011

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

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

...