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

Код, который Вы отправили, похож на него, должен правильно удалить аутентификационный маркер форм, таким образом, возможно, что рассматриваемые папки/страницы на самом деле не защищены.

Вы подтвердили, что к страницам нельзя получить доступ, прежде чем вход в систему произошел?

можно ли отправить web.config настройки и войти ли в систему код, который Вы используете?

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

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

Звуки мне как Вы не имеют Вашего web.config раздела авторизации настроенным правильно в. Посмотрите ниже для примера.

<authentication mode="Forms">
  <forms name="MyCookie" loginUrl="Login.aspx" protection="All" timeout="90" slidingExpiration="true"></forms>
</authentication>
<authorization>
  <deny users="?" />
</authorization>

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

Я писал базовый класс для всех своих страниц и столкнулся с той же проблемой. У меня был код, подобный следующему, и он не работал. Отслеживая, управление переходит от оператора RedirectToLoginPage () к следующей строке без перенаправления.

if (_requiresAuthentication)
{
    if (!User.Identity.IsAuthenticated)
        FormsAuthentication.RedirectToLoginPage();

    // check authorization for restricted pages only
    if (_isRestrictedPage) AuthorizePageAndButtons();
}

Я обнаружил, что есть два решения. Либо изменить FormsAuthentication.RedirectToLoginPage (); быть

if (!User.Identity.IsAuthenticated)
    Response.Redirect(FormsAuthentication.LoginUrl);

ИЛИ изменить web.config, добавив

<authorization>
  <deny users="?" />
</authorization>

Во втором случае во время трассировки элемент управления не достиг запрошенной страницы. Он был сразу же перенаправлен на URL входа в систему, прежде чем достигнуть точки останова. Следовательно, метод SignOut () не является проблемой, метод перенаправления - один.

Я надеюсь, что это может кому-то помочь

С уважением

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

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

Ключевым моментом здесь является то, что вы говорите: «Если я ввожу URL-адрес напрямую ...».

По умолчанию при проверке подлинности с помощью форм браузер кеширует страницы для пользователя. Таким образом, выбрав URL-адрес непосредственно из раскрывающегося списка адресного окна браузера или введя его, МОЖЕТ получить страницу из кеша браузера и никогда не возвращаться на сервер для проверки аутентификации / авторизации. Решением этой проблемы является предотвращение кэширования на стороне клиента в событии Page_Load каждой страницы или в OnLoad () вашей базовой страницы:

Response.Cache.SetCacheability(HttpCacheability.NoCache);

Вы также можете позвонить:

Response.Cache.SetNoStore();

Я тоже боролся с этим раньше.

Вот аналогия тому, что, кажется, происходит ... Новый посетитель, Джо, заходит на сайт и входит через страницу входа, используя FormsAuthentication. ASP.NET создает новую личность для Джо и передает ему файл cookie. Это печенье похоже на ключ от дома, и пока Джо возвращается с этим ключом, он может открыть замок. Каждому посетителю выдается новый ключ и новый замок.

Когда вызывается FormsAuthentication.SignOut () , система сообщает Джо, чтобы он потерял ключ. Обычно это работает, так как у Джо больше нет ключа, он не может войти.

Однако, если Джо когда-нибудь вернется, а действительно имеет этот потерянный ключ, его снова впустят!

Насколько я могу судить, нет никакого способа сказать ASP.NET сменить замок на двери!

Я могу жить с этим, запоминая имя Джо в переменной сеанса. Когда он выходит из системы, я выхожу из сеанса, поэтому у меня больше нет его имени. Позже, чтобы проверить, разрешен ли он, я просто сравниваю его Identity.Name с тем, что есть в текущем сеансе, и если они не совпадают, он не является действительным посетителем.

Короче говоря, для веб-сайта НЕ полагайтесь на User.Identity.IsAuthenticated без проверки переменных сеанса!