2010-12-13 15 views
3

最初のものが最初です。これはサンプルにすぎません。これが認証を行う有効な方法であるかどうかは疑問ではありません。ASP.NET MVC Authorize属性がIEとFireFoxで異なる動作をする

基本的に、使用されているブラウザに依存する奇妙な動作が発生しています。 Firefoxではすべてが期待どおりに機能しますが、IE上では、認証が失敗してもコントローラの操作がまだ実行されます。

私はSecureControllerクラスには、次の該当するコードを標準コントローラクラスから継承する設定ASP.NET MVCテストサイトがありますので、のようなAuthorizeAttributeに基づいてAuthorizeByTokenAttribute属性もあります

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

を:

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ではなく、Webサイト全体のルートにリダイレクトしようとしていますか? – Aaronontheweb

+0

RedirectResult( "/")がWebサイトではなくコントローラのルートにリダイレクトされていることをお勧めしますか?私はそれがそのように動作するとは思っていなかったり、ルーティングがどのように機能するかを壊すでしょう。間違っても私を訂正してください。いずれにせよ、これはブラウザの選択によって影響を受けない、完全にサーバーに含まれた動作であることは間違いありませんか? – nathanchere

+0

私はフードを開いて質問に答える前に、あなたの目標が何であるかを理解しようとしています。あなたの問題は、各ブラウザが相対的なUrisを処理する方法と、各ブラウザでCookieの動作がどのように機能するかという2つの領域のいずれかにあります。私は今すぐ、項目#1を削除または確認するための実験を設定しています。 – Aaronontheweb

答えて

3

私はあなたのUriルーティング方式をいくつかの異なる方法でテストし、それを問題として取り除きました。これは、両方のブラウザで同等に機能します。私はそのようなことについては極度に妄想的です。

したがって、2つのブラウザインスタンスで異なるCookieingの動作または状態だと思う傾向があります。次のことを試してみてください。

  1. はIE8/IE9でInPrivateセッションを使用して、フォームに対して認証するために試してみてください - これは、クッキーレスセッションであり、通常のポストに失敗ルーティング行動で失敗しなければなりません。私たちがこのテストで取り除こうとしているのは、IEセッションでクッキーが汚れていて、Firefoxでクッキーがクリーンである可能性があるということです。このテストが成功する場合は、手順2に進みます。失敗した場合は、手順3を参照してください。
  2. 標準のIEインスタンスを使用してコントローラに対して認証を試みます。失敗した場合は、すべてのCookieを消去してもう一度お試しください。失敗した場合は、手順3を参照してください。
  3. これらの両方のテストが失敗した場合は、FirefoxとIEのCookieが同等かどうかを確認する必要があります。 http://ncookiereader.sourceforge.net/のようなものを使ってFirefoxとIEであなたのサイトのクッキーを比較することができますが、単にクッキーコレクションを開いてメモ帳++で比較するほうが簡単かもしれません。あなたのクッキーの内容は暗号化されるでしょうし、2つの異なるIISセッションで実行されているため異なる認証チケットが含まれている可能性があります。はデバッグの目的でのみ使用しますオプションとして復号化を有効にすることをおすすめしますWeb.configのこのスニペットを使用して平文でクッキーを表示してください:<authentication mode="Forms"> <forms loginUrl="~/Account/LogOn" timeout="2880" protection="None" /> </authentication> - クッキーの内容が認証チケット以外のものと著しく異なる場合は、http://aaronstannard.com/にアクセスし、お問い合わせフォームからメールをお送りください。 Cookieの内容が同等の場合は、手順4に進みます。
  4. この時点では、認証フィルタで手渡されていない例外を探し始めます.Wiresharkを使用して、HTTPリクエストがIEとFirefoxは大きな違いがあります。何かを見つけたらお知らせください。
関連する問題