3

カスタムClaimsAuthorizationManagerを使用してMVCで承認を行っていますが、問題が発生しています。

  • CheckAccessメソッドで単に「true」を返したとしても、次の理由により、すべてのファイル/画像が500ランタイムエラーでブロックされています。

例外情報：例外タイプ：NotSupportedException例外メッセージ：ID1075：現在のプリンシパル（HttpContext.Current.User）がClaimsPrincipalでないと、ClaimsAuthorizationModuleを使用できません。System.IdentityModel.Services.ClaimsAuthorizationModule.Authorize（）で

アプリケーションの早い段階で現在のプリンシパルに関して何も変更していません...考えますか？私は困惑していて、そのエラーを検索しても何もわかりません...

<system.webServer>    
    <modules>      
      ...
      <add name="ClaimsAuthorizationModule" type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </modules>
</system.webServer>


  <system.identityModel>
    <identityConfiguration>
      <claimsAuthorizationManager type="NamespaceFun.CustomAuthorizationManager, NamespaceFun" >
    <policy resource="http://localhost:52606/" action="GET">
    </policy>
      </claimsAuthorizationManager>
      ...
    </identityConfiguration>
   </system.identityModel>


public class CustomAuthorizationManager : ClaimsAuthorizationManager
{      
    public override bool CheckAccess(AuthorizationContext context)
    {   
        return true;            
    }       
}
4

4 に答える 4

5

同じ問題が発生したので、web.configをWIFブックの1つと比較しましたpreCondition="managedHandler"が、add要素の最後から欠落していることがわかり、あなたも欠落しているようです。

また、MSDNの例から欠落しているようです。

正しい方法： 

<add name="ClaimsAuthorizationModule" 
     type="System.IdentityModel.Services.ClaimsAuthorizationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 
     preCondition="managedHandler" />
于 2013-03-18T18:39:36.913 に答える
2

質問をして、1時間後に自分で答えると思います。しかし、これは私を何日も当惑させました。それが実際に私が他のことを成し遂げることを妨げていたので、私はそれを掘り下げなければなりませんでした。

とにかく、私がしたことはかなり単純でした。MicrosoftのClaimsAuthorizationManagerのこの例では、画像の提供に問題はありません。 http://code.msdn.microsoft.com/vstudio/Claims-Aware-MVC-523e079b

そこで、両方のアプリケーションのWeb.configファイルを比較したところ、「驚くほど」類似していることがわかりました。

唯一の違いは、イントラネットアプリケーションのsystem.webServerセクションに次のハンドラーが含まれていることです。

 <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

私は実際にこれらが何をしているのかを理解する必要がありますが、現時点では、それらを削除することで私の元の問題は解決します。

私の意見では、WIFは依然として巨大な「ブラックボックス」です。エラーをグーグルで検索しても何も返されない場合、新しいテクノロジーを採用するのは困難です。

于 2013-03-18T18:06:27.813 に答える
1

実際、クレーム承認モジュールを使用するのは本当に悪い考えだと思います。その理由は、モジュールがURLに基​​づいているためですが、MVCでは、すべてがルーティングテーブルまたはコントローラー/アクションからキーオフされます。

2つが同期しなくなると、承認ポリシーに穴が開く可能性があります（さらに、すでに発生した静的ファイルの問題もあります）。私は実際には属性ベースのアプローチを好みます-ASP.NETでうまく機能する属性（MVC用に1つ、Web API用に1つ）を承認するために構築しました：

http://leastprivilege.com/2012/10/26/using-claims-based-authorization-in-mvc-and-web-api/

于 2013-03-19T07:26:52.920 に答える
0

私の場合、カスタムのClaimsAuthorizationManagerを使用しているときにファイル（JavaScriptを含む）がブロックされていた理由は、runAllManagedModulesForAllRequestsmodulesタグの属性が原因でした。

<modules runAllManagedModulesForAllRequests="true">

これにより、リクエストが管理対象コンテンツに対するものでなかった場合でも、カスタムClaimsAuthorizationManagerによるすべてのリクエストが処理されます。その属性を削除すると、問題が解決します。

于 2015-04-27T03:13:16.803 に答える