FormsAuthentication.SignOut () не выходит из системы

Question

Слишком долго разбил мне голову об этом. Как запретить пользователю просматривать страницы сайта после того, как они вышли из системы с помощью FormsAuthentication.SignOut? Я ожидал бы, что это сделает это:

FormsAuthentication.SignOut();
Session.Abandon();
FormsAuthentication.RedirectToLoginPage();

Но это не так. Если я введу URL-адрес напрямую, я все равно смогу перейти на страницу. Я давно не пользуюсь защитой по собственной инициативе, поэтому забываю, почему это не работает.

Answer 1

Я только что попробовал некоторые из предложенных здесь советов, и хотя я смог использовать кнопку «Назад» браузера, когда я щелкнул по выбору меню, токен [Authorize] для этого [ActionResult] отправил меня обратно на экран входа в систему.

Вот мой код выхода из системы:

        FormsAuthentication.SignOut();
        Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
        Response.Cache.SetExpires(DateTime.Now.AddSeconds(-1));
        HttpCookie cookie = HttpContext.Request.Cookies[FormsAuthentication.FormsCookieName];
        if (cookie != null)
        {
            cookie.Expires = DateTime.Now.AddDays(-1);
            Response.Cookies.Add(cookie);
        }

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

Надеюсь, это поможет

Answer 2

Я попробовал большинство ответов в этой теме, не повезло. Закончилось этим:

protected void btnLogout_Click(object sender, EventArgs e)
{
    FormsAuthentication.Initialize();
    var fat = new FormsAuthenticationTicket(1, "", DateTime.Now, DateTime.Now.AddMinutes(-30), false, string.Empty, FormsAuthentication.FormsCookiePath);
    Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(fat)));
    FormsAuthentication.RedirectToLoginPage();
}

Нашел здесь: http://forums.asp.net/t/1306526.aspx/1

Answer 3

Это начало происходить со мной, когда я установил аутентификация> формы> Свойство пути в Web.config. Устранение, которое решило проблему, и простой FormsAuthentication.SignOut(); снова удалил cookie.

Answer 4

Для меня работает следующий подход. Я думаю, что если после оператора «FormsAuthentication.SignOut ()» возникнет ошибка, SingOut не будет работать.

public ActionResult SignOut()
    {
        if (Request.IsAuthenticated)
        {
            FormsAuthentication.SignOut();

            return Redirect("~/");
        }
        return View();
     }

Answer 5

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

if(Session["UserID"] == null || Session["UserID"] == "")
{
    Response.Redirect("Login.aspx");
}

Answer 6

Возможно, вы входите с одного субдомена (sub1.domain.com), а затем пытаетесь выйти из другого субдомена (www.domain.com).

Answer 7

У меня сейчас похожая проблема, и я считаю, что проблема в моем случае, как и в оригинальном постере, связана с перенаправлением. По умолчанию Response.Redirect вызывает исключение, которое немедленно всплывает, пока не будет перехвачено, и перенаправление немедленно выполнено, я предполагаю, что это предотвращает передачу измененной коллекции cookie клиенту. Если вы измените свой код для использования:

Response.Redirect("url", false);

Это предотвращает исключение и, по-видимому, позволяет правильно отправлять cookie клиенту.

Answer 8

У меня была та же проблема, когда SignOut (), похоже, не смог правильно удалить тикет. Но только в конкретном случае, когда какая-то другая логика вызвала перенаправление. После того как я удалил этот второй редирект (заменил его сообщением об ошибке), проблема исчезла.

Проблема, возможно, заключалась в том, что страница перенаправлялась в неправильное время, следовательно, не запускала аутентификацию.

Answer 9

Я хотел добавить информацию, чтобы помочь понять проблему. Проверка подлинности с помощью форм позволяет хранить пользовательские данные либо в файле cookie, либо в строке запроса URL-адреса. Метод, поддерживаемый вашим сайтом, можно настроить в файле web.config.

По данным Microsoft :

Метод SignOut удаляет информацию о билете аутентификации форм из файла cookie или URL-адреса , если CookiesSupported имеет значение false .

В то же время они говорят :

Одно из значений HttpCookieMode, которое указывает, является ли Приложение настроено для проверки подлинности без файлов cookie. The по умолчанию используется UseDeviceProfile .

Наконец, что касается UseDeviceProfile, они говорят :

Если для свойства CookieMode установлено значение UseDeviceProfile, Свойство CookiesSupported вернет true, если Браузер для текущий запрос поддерживает как куки, так и перенаправление с куки ; в противном случае свойство CookiesSupported вернет false.

Соединяя все это вместе, в зависимости от браузера пользователя, конфигурация по умолчанию может привести к тому, что CookiesSupported будет true , что означает, что метод SignOut не удаляет билет из куки. Это кажется нелогичным, и я не знаю, почему это работает таким образом - я бы ожидал, что SignOut действительно выписывает пользователя при любых обстоятельствах.

Один из способов заставить SignOut работать самостоятельно - изменить режим файлов cookie на «UseCookies» (т. Е. Необходимы файлы cookie) в файле web.config:

<authentication mode="Forms">
  <forms loginUrl="~/Account/SignIn" cookieless="UseCookies"/>
</authentication>

Согласно моим тестам, это делает SignOut работающим само по себе за счет вашего сайта, теперь требующего, чтобы куки работали должным образом.

Answer 10

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

(Я видел такое поведение, даже когда вы входите в систему как другой пользователь, и IE отображает панель «Добро пожаловать» в верхней части вашей страницы со старым именем пользователя. В настоящее время обычно перезагрузка обновляет его, но если он постоянен, он все еще может быть проблемой кеширования.)