2010-12-13 4 views
3

첫 번째 사항 먼저 : 이것은 예제 일뿐입니다. 이것이 유효한 인증 방법인지 여부는 문제가되지 않습니다.ASP.NET MVC 권한 부여 특성은 IE와 FireFox에서 다르게 동작합니다.

기본적으로 사용중인 브라우저에 따라 이상한 동작이 나타납니다. 모든 것이 파이어 폭스에서 예상대로 작동하지만, IE에서는 의심스러운 컨트롤러 동작이 인증이 실패하더라도 여전히 작동합니다.

[AuthorizeByToken] 
public class SecureController : Contrller 
protected override void OnAuthorization(AuthorizationContext filterContext) 
{ 
    // Check for presence of encoded session string 
    if (filterContext == null) throw new ArgumentNullException("filterContext null"); 
    if (filterContext.HttpContext == null) throw new ArgumentNullException("httpContext null"); 
    if (filterContext.HttpContext.Request["TestToken"] == null) return; 

    // Complete authorization 
    FormsAuthentication.SetAuthCookie(csmSession.CSMUser.userName, true); 
    base.OnAuthorization(filterContext); 
} 

도과 같이 AuthorizeAttribute을 기반으로 AuthorizeByTokenAttribute 속성이있다 :

나는 SecureController 클래스는 다음과 같은 관련 코드와 표준 컨트롤러 클래스에서 상속 곳에는 ASP.NET MVC 테스트 사이트가 설정 한

public class AuthorizeByTokenAttribute : AuthorizeAttribute 
{ 
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext) 
    { 
     filterContext.Result = new RedirectResult("/"); 
     filterContext.ActionDescriptor = null; 
     base.HandleUnauthorizedRequest(filterContext); 
    } 

} 

예를 들어 http://testsite/TestSecureController/Index을 방문하면 Firefox에서 예상대로 작동합니다. 권한 부여 코드로 들어가 실패하고 루트로 리디렉션됩니다. IE에서는 코드를 인증하고 여전히 실패하고 다음 단계는 TestSecureController의 Index() 액션 실행입니다.

누구든지 브라우저와 관련이있는 이유에 대한 통찰력을 제공 할 수 있습니까?

+1

몇 가지 질문 : 1.이 컨트롤러의 루트 인 Index() 작업 메서드가 아닙니까? 2.이 속성으로 장식 된 SecureContoller 대신 전체 웹 사이트의 루트로 리디렉션하려고합니까? – Aaronontheweb

+0

RedirectResult ("/")가 웹 사이트가 아닌 컨트롤러의 루트로 리디렉션되는 것이 좋습니다. 나는 그것이 그런 식으로 작동 할 것이라고 생각하지 않았을 것이거나 라우팅이 어떻게 작동하는지 깨뜨릴 것입니다. 잘못하면 나를 바로 잡으십시오. 어느 쪽이든, 분명히 이것은 브라우저의 선택에 영향을받지 않는 완전히 서버가 포함 된 동작입니까? – nathanchere

+0

나는 두포를 열고 질문에 대답하기 전에 목표가 무엇인지 이해하려고 노력하고 있습니다. 문제는 각 브라우저가 상대적 Uris를 처리하는 방법과 각 브라우저에서 쿠키 동작이 작동하는 방법 중 하나에 있습니다. 나는 항목 # 1을 제거하거나 확인하기 위해 지금 실험을 준비 중입니다. – Aaronontheweb

답변

3

몇 가지 다른 방법을 사용하여 귀하의 Uri 라우팅 방식을 테스트 한 결과 문제가 해결되었습니다. 이는 두 브라우저에서 동등하게 작동합니다. 나는 그런 종류의 일에 대해 매우 편집 적이다.

따라서 두 브라우저 인스턴스에서 서로 다른 쿠키 동작 또는 상태라고 생각합니다. 다음보십시오 :

  1. 시도가 IE8/IE9에서은 InPrivate 세션을 사용하여 양식에 대한 권한을 부여 -이 쿠키 세션과 정상 후 실패 라우팅 동작을 실패합니다. 이 테스트로 제거하려는 것은 IE 세션에서 쿠키가 더럽고 Firefox에서 쿠키를 정리할 가능성이 있습니다. 이 테스트가 성공하면 2 단계로 진행합니다. 실패하면 3 단계를 참조하십시오.
  2. 표준 IE 인스턴스를 사용하여 컨트롤러에 대해 권한을 부여하십시오. 실패하면 모든 쿠키를 지우고 다시 시도하십시오. 실패 할 경우 3 단계를 참조하십시오.
  3. 두 테스트가 모두 실패한 경우 Firefox와 IE의 쿠키가 동일한 지 확인해야합니다. http://ncookiereader.sourceforge.net/과 같은 것을 사용해 Firefox와 IE에서 사이트가 발행하는 쿠키를 비교할 수 있지만 쿠키 컬렉션을 열어서 메모장 + +에서 비교하는 것이 더 간단 할 수도 있습니다. 쿠키의 내용은 암호화 될 것이고 다른 IIS 세션에서 실행 중이기 때문에 서로 다른 인증 티켓을 포함 할 수 있습니다. 따라서 편리하게 사용하려면 디버깅 용으로 만 사용하십시오. 옵션으로 암호 해독을 사용하도록 설정하는 것이 좋습니다. Web.config에서이 스 니펫을 사용하여 일반 텍스트로 쿠키를 봅니다. <authentication mode="Forms"> <forms loginUrl="~/Account/LogOn" timeout="2880" protection="None" /> </authentication> - 쿠키 내용이 인증 티켓 이외의 다른 내용 인 경우 http://aaronstannard.com/으로 이동하여 연락처 양식을 통해 전자 메일을 보내주십시오. 쿠키의 내용이 동일하면 4 단계로 진행하십시오.
  4. 이 시점에서 인증 필터에서 처리되지 않은 예외를 찾기 시작하고 Wireshark를 사용하여 HTTP 요청이 IE 및 파이어 폭스는 큰 차이가있다. 뭔가를 찾으면 알려주세요.
관련 문제