programing

폼 인증Sign Out()은 사용자를 로그아웃하지 않습니다.

telebox 2023. 4. 22. 09:17
반응형

폼 인증Sign Out()은 사용자를 로그아웃하지 않습니다.

내 머리를 너무 오래 부딪혔어사용자가 양식을 사용하여 로그아웃한 후 사이트의 페이지를 참조하지 못하도록 하려면 어떻게 해야 합니까?인증.사인아웃?이렇게 하면 될 것 같아요.

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

하지만 그렇지 않다.URL을 직접 입력해도 페이지를 참조할 수 있습니다.한동안 Roll-Your-Own 보안 기능을 사용하지 않아서 이 기능이 작동하지 않는 이유를 잊었습니다.

할 수 은, 「」를 해도, 않기 때문입니다.FormsAuthentication.SignOut()새로운 요구가 있을 때마다 인증됩니다.MS 문서에는 cookie는 클리어되지만 cookie는 클리어되지 않는다고 되어 있습니다.버그? 부분은 its its its와 its its its its its its its its its its?Session.Abandon()는 아직

코드를 다음과 같이 변경해야 합니다.

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

// clear authentication cookie
HttpCookie cookie1 = new HttpCookie(FormsAuthentication.FormsCookieName, "");
cookie1.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie1);

// clear session cookie (not necessary for your current problem but i would recommend you do it anyway)
SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/sessionState");
HttpCookie cookie2 = new HttpCookie(sessionStateSection.CookieName, "");
cookie2.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie2);

FormsAuthentication.RedirectToLoginPage();

HttpCookie에 있습니다.System.Web네임스페이스.MSDN 레퍼런스

위의 x64igor와 Phil Haselden의 투고 중 2개를 사용하여 이 문제를 해결했습니다.

1. x64igor는 로그아웃을 실행하는 예를 제시했습니다.

  • 먼저 로그아웃에 대한 응답에서 빈 쿠키를 반환하여 Authentication CookieSession Cookie를 클리어해야 합니다.

    public ActionResult LogOff()
    {
        FormsAuthentication.SignOut();
        Session.Clear();  // This may not be needed -- but can't hurt
        Session.Abandon();
    
        // Clear authentication cookie
        HttpCookie rFormsCookie = new HttpCookie( FormsAuthentication.FormsCookieName, "" );
        rFormsCookie.Expires = DateTime.Now.AddYears( -1 );
        Response.Cookies.Add( rFormsCookie );
    
        // Clear session cookie 
        HttpCookie rSessionCookie = new HttpCookie( "ASP.NET_SessionId", "" );
        rSessionCookie.Expires = DateTime.Now.AddYears( -1 );
        Response.Cookies.Add( rSessionCookie );
    

2. Phil Haselden은 위의 로그아웃 후 캐싱을 방지하는 예를 제시했습니다.

  • 응답을 통해 클라이언트 측의 캐시를 비활성화해야 합니다.

        // Invalidate the Cache on the Client Side
        Response.Cache.SetCacheability( HttpCacheability.NoCache );
        Response.Cache.SetNoStore();
    
        // Redirect to the Home Page (that should be intercepted and redirected to the Login Page first)
        return RedirectToAction( "Index", "Home" ); 
    }
    

web.config 권한 부여 섹션이 에서 올바르게 설정되어 있지 않은 것 같습니다.예에 대해서는, 이하를 참조해 주세요.

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

여기서 중요한 것은 "URL을 직접 입력하면...".

기본적으로 양식 인증에서 브라우저는 사용자의 페이지를 캐시합니다.따라서 브라우저 주소 상자 드롭다운에서 URL을 직접 선택하거나 입력하면 브라우저 캐시에서 페이지를 가져오고 인증/허가를 확인하기 위해 서버로 돌아가지 않습니다.이에 대한 해결책은 각 페이지의 Page_Load 이벤트 또는 기본 페이지의 OnLoad()에서 클라이언트 측 캐싱을 방지하는 것입니다.

Response.Cache.SetCacheability(HttpCacheability.NoCache);

또, 다음과 같이 전화할 수도 있습니다.

Response.Cache.SetNoStore();

저도 예전에 고생한 적이 있어요.

여기 무슨 일이 일어나고 있는지 유추해 보겠습니다.새로운 방문자 Joe는 사이트에 접속하여 로그인 페이지에서 Forms를 사용하여 로그인합니다.인증.ASP.NET은 Joe의 새로운 아이덴티티를 생성하고 그에게 쿠키를 제공합니다.그 쿠키는 집 열쇠와 같아서 조가 그 열쇠를 가지고 돌아오기만 하면 자물쇠를 열 수 있어각 방문자에게는 새로운 키와 사용할 수 있는 새로운 잠금이 주어집니다.

FormsAuthentication.SignOut()호출되면 시스템은 Joe에게 키를 잃어버리도록 지시합니다.보통 이렇게 하면 됩니다.조우는 더 이상 열쇠를 가지고 있지 않기 때문에 들어갈 수 없습니다.

하지만, 만약 조가 다시 돌아오면, 그리고 잃어버린 열쇠를 가지고 있다면, 그는 다시 들어갈 수 있습니다!

제가 알기로는 ASP에 알릴 방법이 없습니다.문의 잠금을 변경하는 NET!

세션 변수에서 조의 이름을 기억하는 것이 내가 견딜 수 있는 방법이다.그가 로그아웃하면, 나는 세션을 포기해서 더 이상 그의 이름을 알지 못한다.나중에, 그가 들어올 수 있는지 확인하기 위해, 나는 그의 신분을 간단히 비교한다.현재 세션의 이름을 지정하십시오. 일치하지 않으면 유효한 방문자가 아닙니다.

웹 , ,, 이, 이, 이, 웹에 의존하지 .User.Identity.IsAuthenticated★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★!

많은 검색 후에 마침내 이것은 나에게 효과가 있었다.도움이 됐으면 좋겠어요.

public ActionResult LogOff()
{
    AuthenticationManager.SignOut();
    HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);
    return RedirectToAction("Index", "Home");
}

<li class="page-scroll">@Html.ActionLink("Log off", "LogOff", "Account")</li>

난 이거면 돼

public virtual ActionResult LogOff()
    {
        FormsAuthentication.SignOut();
        foreach (var cookie in Request.Cookies.AllKeys)
        {
            Request.Cookies.Remove(cookie);
        }
        foreach (var cookie in Response.Cookies.AllKeys)
        {
            Response.Cookies.Remove(cookie);
        }
        return RedirectToAction(MVC.Home.Index());
    }

이 답변은 Khosro와 기술적으로 동일합니다.파크마네쉬.이 스레드에서 그의 답변이 다른 답변과 어떻게 다른지, 그리고 어떤 경우에 사용할 수 있는지 명확히 하기 위해 게시합니다.

일반적으로 사용자 세션을 클리어하기 위해

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

는 사용자를 효과적으로 로그아웃시킵니다., 같은 요청에서 체크할 필요가 있는 경우Request.isAuthenticated를 들어 Filter에서 수 경우는 다음과 같습니다(Authorization Filter 등 ( ( ( ( ( ( ) 。

Request.isAuthenticated == true

당신이 한 HttpContext.Session.Abandon() ★★★★★★★★★★★★★★★★★」FormsAuthentication.SignOut().

유일하게 효과가 있었던 건

AuthenticationManager.SignOut();
HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);

하면 실질적으로 이 됩니다.Request.isAuthenticated = false.

게시한 코드는 양식 인증 토큰을 올바르게 삭제해야 하므로 해당 폴더/페이지가 실제로 보호되지 않을 수 있습니다.

로그인하기 전에 페이지에 액세스할 수 없음을 확인하시겠습니까?

사용하고 있는 web.config 설정 및 로그인 코드를 게시할 수 있습니까?

모든 페이지에 대해 기본 클래스를 작성했는데 같은 문제에 도달했습니다.나는 다음과 같은 코드를 가지고 있었지만 작동하지 않았다.트레이스를 통해 컨트롤은 RedirectToLoginPage() 스테이트먼트에서 다음 행으로 리다이렉트되지 않고 전달됩니다.

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

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

나는 두 가지 해결책이 있다는 것을 알았다.양식 수정 중 하나인증.RedirectToLoginPage(); 대상

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

또는 를 추가하여 web.config를 변경합니다.

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

두 번째 경우 추적 중 컨트롤이 요청된 페이지에 도달하지 않았습니다.중단점에 도달하기 전에 로그인 URL로 즉시 리다이렉트되었습니다.따라서 Sign Out() 메서드가 문제가 아니라 리다이렉트 메서드가 문제가 됩니다.

그게 도움이 됐으면 좋겠는데

안부 전해요

여기서 몇 가지 제안을 시도해 봤는데 브라우저의 뒤로 버튼을 사용할 수 있는 동안 메뉴 선택을 클릭하자 [ActionResult]에 대한 [Authorize]토큰이 바로 로그인 화면으로 돌아갔습니다.

로그아웃 코드는 다음과 같습니다.

        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);
        }

브라우저의 Back 기능으로 보안 메뉴가 표시되지만(아직 작업 중) 앱에서 보안으로 보호된 것은 할 수 없었습니다.

도움이 되었으면 좋겠다

난 이 상황에서 대부분의 답을 시도해봤지만, 운이 없었어.결국 다음과 같은 결과가 되었습니다.

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

이 문제는 에서 authentication > forms > Path 속성을 설정했을 때 발생하기 시작했습니다.Web.config가 해결되고 가 해결됩니다.FormsAuthentication.SignOut();다시 쿠키를 제거했다.

1개의 서브 도메인(sub1.domain.com)에서 로그인하고 나서, 다른 서브 도메인(www.domain.com)에서 로그아웃 하려고 하는 경우가 있습니다.

Sign Out()이 티켓을 제대로 삭제하지 못한 것 같은 문제가 있었습니다.하지만 다른 논리가 리다이렉트를 일으킨 특정한 경우에만요이 두 번째 리다이렉트를 삭제(에러 메시지로 대체)한 후 문제가 해결되었습니다.

문제는 페이지가 잘못된 시각에 리다이렉트되어 인증을 트리거하지 않았다는 것입니다.

저는 지금 비슷한 문제를 겪고 있는데, 원래의 포스터뿐만 아니라 제 사례에서도 문제가 있는 것은 리다이렉트 때문이라고 생각합니다.기본적으로는 응답입니다.리다이렉트하면 예외가 발생하여 리다이렉트가 즉시 실행될 때까지 버블이 발생합니다.이것에 의해, 변경된 cookie 컬렉션이 클라이언트에 건네지는 것을 방해하고 있는 것이 아닌가 생각합니다.사용할 코드를 수정하는 경우:

Response.Redirect("url", false);

이것에 의해, 예외가 방지되어 cookie가 클라이언트에 올바르게 되돌려지는 것이 가능하게 됩니다.

로그인을 누를 때 세션 변수를 보내기만 하면 됩니다.그리고 시작 페이지에서 먼저 해당 세션이 페이지 로드 또는 초기화 이벤트에서 다음과 같이 비어 있는지 확인합니다.

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

문제를 이해하는 데 도움이 되는 정보를 추가하고 싶었습니다.[ Forms Authentication ]를 사용하면 사용자 데이터를 쿠키 또는 URL 쿼리 문자열에 저장할 수 있습니다.사이트에서 지원하는 방법은 web.config 파일에서 구성할 수 있습니다.

마이크로소프트에 따르면:

SignOut 메서드는 쿠키 또는 URL에서 폼 인증 티켓 정보를 삭제합니다.Supported는 false입니다.

동시에 다음과 같이 말합니다.

응용 프로그램이 쿠키 없는 형식 인증용으로 설정되어 있는지 여부를 나타내는 HttpCookieMode 값 중 하나.기본값은 Use Device Profile 입니다.

마지막으로 Use Device Profile에 대해 다음과 같이 말합니다.

CookieMode 속성이 UseDeviceProfile로 설정되어 있는 경우 Cookie는현재 요청대한 브라우저쿠키와 쿠키를 사용리디렉션을 모두 지원하는 경우 Supported 속성이 true로 반환됩니다.그렇지 않으면 쿠키가 true로 반환됩니다.지원되는 속성은 false를 반환합니다.

이 모든 것을 조합하면 사용자의 브라우저에 따라 기본 구성이 쿠키가 될 수 있습니다.Supported be true. 즉, SignOut 메서드는 쿠키에서 티켓을 클리어하지 않습니다.이것은 직관에 반하는 것 같습니다만, 왜 이렇게 동작하는지는 모르겠습니다.SignOut은 어떤 상황에서도 실제로 사용자를 로그아웃 시킬 수 있을 것입니다.

SignOut을 단독으로 동작시키는 방법 중 하나는 web.config 파일에서 쿠키 모드를 "UseCookies"(쿠키가 필요함)로 변경하는 것입니다.

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

제 테스트에 따르면, 이렇게 하면 사이트 비용을 들여 SignOut이 자동으로 작동하게 됩니다.이제 쿠키가 제대로 작동해야 합니다.

저에게는 다음과 같은 접근방식이 효과적입니다."Forms Authentication" 후에 오류가 있는지 확인합니다.Sign Out()" 문, Sing Out이 작동하지 않습니다.

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

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

IE를 사용하여 이 동작을 테스트/확인하고 있습니까?IE가 캐시에서 이러한 페이지를 서비스하고 있을 가능성이 있습니다.IE가 캐시를 플러시하도록 하는 것은 어렵기로 악명이 높기 때문에 로그아웃 후에도 많은 경우 "보안" 페이지 중 하나의 URL을 입력하면 이전에 캐시된 콘텐츠가 나타납니다.

(다른 사용자로 로그인해도 이 동작을 볼 수 있습니다.IE 에서는, 페이지 상부에 낡은 유저의 유저명과 함께 「Welcome」바에 표시됩니다.현재는 보통 새로고침으로 갱신되지만, 영속적인 경우에는 캐싱의 문제가 될 수 있습니다.

Session.abandon()을 실행하여 쿠키를 파기하면 상당히 효과가 있습니다.mvc3를 사용하고 있는데 보호된 페이지로 이동하여 로그아웃하고 브라우저 기록을 검색하면 문제가 발생하는 것 같습니다.별거 아닌데도 좀 짜증나네.

내 웹 앱에서 링크를 통과하려고 하는 것은 올바른 방법으로 작동한다.

브라우저 캐시를 수행하지 않도록 설정하는 것이 좋습니다.

MVC의 경우 다음과 같이 처리됩니다.

        public ActionResult LogOff()
        {
            FormsAuthentication.SignOut();
            return Redirect(FormsAuthentication.GetRedirectUrl(User.Identity.Name, true));
        }

WIF는 STS로부터의 wsignout cleanup 메시지가 IIS로부터의 응용 프로그램 이름과 URL이 일치하지 않을 경우 브라우저에 쿠키를 정리하도록 지시하는 것을 거부합니다.즉, 대소문자를 구분합니다.WIF는 녹색 OK 체크로 응답하지만 쿠키를 삭제하는 명령어는 브라우저로 전송하지 않습니다.

따라서 URL의 대소문자를 구분해야 합니다.

예를 들어 ThinkTecture Identity Server는 Visiting RP의 URL을 하나의 쿠키에 저장하지만 모두 소문자로 만듭니다.WIF는 소문자로 wsignoutcleanup 메시지를 수신하여 IIS의 응용 프로그램 이름과 비교합니다.일치하지 않으면 쿠키는 삭제되지 않지만 브라우저에 OK가 보고됩니다.따라서 이 ID 서버에서는 이러한 문제를 피하기 위해 web.config에 모든 URL을 쓰고 IIS에 모든 응용 프로그램 이름을 소문자로 써야 했습니다.

또한 STS의 서브도메인 외부에 어플리케이션이 있는 경우 브라우저 내에서 서드파티 쿠키를 허용해야 합니다.그렇지 않으면 WIF에서 쿠키가 삭제되어도 브라우저는 쿠키를 삭제하지 않습니다.

언급URL : https://stackoverflow.com/questions/412300/formsauthentication-signout-does-not-log-the-user-out

반응형