1

ACL を使用しようとしていますが、提案されているように、セキュリティ戦略を に切り替えましたunanimous。

それ以来、いくつかの URL が私のユーザーにアクセスを許可しなくなりました。
ただし、ファイアウォールの構成に従っている必要があります（デフォルトの戦略でこれを制御できます）。

少なくとも 1 人の有権者が許可しない場合、満場一致の戦略ではアクセスが拒否されることを理解しています。

質問は次のとおりです。

アクセスが拒否された場合の特定のリクエストについて、
どの投票者がアクセスを拒否しているかを知るために、どの投票者が関与しているかを知る方法は?

4

3 に答える 3

3

access_decision_manager戦略をunanimousに切り替えてから、同じ問題が発生しました。Symfony 2.4以降、式はデフォルトで組み込まれており、これを使用して問題を解決しました。

アクセス制御で複数のロールを使用するには、次のようにしました。

access_control:
    - { path: ^/, roles: [ROLE_ADMIN, ROLE_MANAGER, ROLE_EDITOR] }

変更後:

access_control:
       - { path: ^/, allow_if: "has_role('ROLE_ADMIN') or has_role('ROLE_MANAGER') or has_role('ROLE_EDITOR')" }

それは全会一致の問題を解決しました。それがあなたや誰かに役立つことを願っています.

于 2014-03-03T03:30:00.470 に答える
0

アクセスが拒否された場合に関係する有権者を確認する方法を見つけることができませんでしたが、

拒否されたものを最終的に見つけました。全会一致の戦略では、security/access_control が複数のロールに対してルートを定義する場合、ユーザーはすべてのロールにアクセス権を付与する必要があります。それは実際には論理的です...

それは質問への答えにはなりませんが、満場一致のセキュリティ戦略を使用する際には、心に留めておくとよいと思います。

于 2013-06-11T12:58:58.273 に答える
0

あなたの質問について: どの有権者がアクセスを拒否しているかを知るために、どの有権者が関与しているかを知る方法は?

答え: サービスでタグ名「security.voter」を検索する必要があります。すべてのセキュリティ有権者はそのように登録されます。これらすべての有権者は常に使用されます。

一部の場合: アクセスが拒否された場合の特定の要求について、

答え：

リクエストごとにトークンに基づいてセキュリティ投票者へのアプローチが異なるため、デバッグなしでアクセスを拒否された投票者を確認することはほとんど不可能です。本当に知りたい場合は、Xdebug などのツールを使用して有権者の流れを確認してください。

ただし、コードの単体テストを作成して、特定のリクエスト時にアクセスできるかどうかを確認できます。

于 2013-12-16T13:45:06.890 に答える