У меня есть веб-сайт, размещенный на IIS 7 с установленным модулем перезаписи URL 2.0 .Он запускается системой управления контентом, которая просматривает URL-адрес и возвращает ошибку 401, если текущий пользователь не имеет разрешения на просмотр страницы.Это обнаруживается модулем авторизации URL-адреса ASP.NET, который затем перенаправляет страницу на страницу loginUrl, как указано в файле web.config
(проверка подлинности форм).
Это отлично работает на моем локальном компьютере, которыйэто IIS 7 и Windows 7.
Если URL, скажем, /612/some-string
, пользователь перенаправляется на страницу входа в систему по адресу /66/login?ReturnUrl=/612/some-string
.
Переписывание URL-адреса выглядит в первой частиURL для идентификатора документа.Реальный URL будет таким: index.aspx?documentId=612
К сожалению, когда я развернул это на нашем промежуточном сервере, ReturnUrl - это не переписанный URL, а оригинальный URL.Это вызывает всевозможные проблемы.
Промежуточным сервером также является IIS 7 с установленным модулем перезаписи URL 2.0.Это Windows 2008 server SP2.Оба работают под управлением ASP.NET 3.5.
Я могу только предположить, что файл machine.config
по-разному упорядочивает httpModules по умолчанию, и модуль аутентификации форм .NET подключается до того, как URL будет перезаписан.
Я скоро рассмотрю, но в то же время, каков опыт с этой проблемой и можно ли ее решить?
Обновление
Я также пытался изменить
Response.StatusCode = 401;
до
FormsAuthentication.RedirectToLoginPage();
, что немного опережает меня, но все же направляет пользователя обратно на URL, который не был переписан.
Я могутакже сделайте это вместо установки 401:
string currentPage = HttpUtility.UrlEncode(Request.RawUrl);
string loginUrl = FormsAuthentication.LoginUrl + "?ReturnUrl=" + currentPage;
Response.Redirect(loginUrl);
Но это кажется уродливым.