0

BackendBundleAPIFrontendBundle用とAngularJS「クライアント」用の2つのバンドルに分割されたSymfony2アプリケーションがあります。すべてがファイアウォールの下で機能します。

BackendBundleエンティティを持ち、API ルートを処理します。FrontendBundleAngular ビュー、ルーティングなどがあり、ワイルドカードを使用したコントローラーは 1 つだけです。

class AngularController extends Controller {
    /**
     * @Route("/{route}", name="angular_index_all_unmatched_routes", requirements={"route" = ".*"})
     * @Template("FrontendBundle::index.html.twig")
     */
    public function angularIndexAction($route) {
        return ['route' => $route];
    }
}

FrontendBundleルーティングは の最後のリソースとして定義されapp/config/routing.yml、他のルートが一致しなかった場合にのみ呼び出されます。そのおかげで、Angular HTML5 モードのルートが直接アクセスされた場合 (たとえば、コピー アンド ペースト) に処理でき、問題なく動作します。

私がやりたいことはAngularController::angularIndexAction()、匿名ユーザーがすべての一致しないルート (によって処理される) にアクセスできるように、ファイアウォールおよび/またはアクセス制御を定義することです。

なんで？一部の API ルートを (フロントエンド プロキシ経由で) 開き、ユーザー以外がアクセスできるようにしたい (たとえば、ユーザーへのメッセージと共にメールで送信された確認 URL)。

匿名の「Angular」ルートごとにアクセス制御リストをハードコーディングしたくありません。API ルートに対してのみ実行したいと考えています。最後に、これらの一致しないルートは Angular のインデックスを開き、ユーザーがログインしているかどうか (完全なレイアウトまたは簡略化されたレイアウトを表示するため) を認識し、Angular ルートを処理し、リクエストが失敗した場合は何らかの「アクセスが拒否されました」というメッセージを表示する必要があります (Symfony リスナーがある場合)そのためのAngularの$provideインターセプター）。

助言がありますか？

編集:@Security注釈はAngularController::angularIndexAction()機能しません。ファイアウォールのエントリ ポイントにリダイレクトされます。

Edit2：ここにの断片がありますsecurity.yml

firewalls:
    unsecured:
        pattern: ^/(_(profiler|wdt)|css|images|js)/
        security: false
        anonymous: true

    secured:
        pattern: '^.*$'
        form_login:
            login_path: /our-provider/login
            check_path: /our-provider/callback/
        anonymous: true
        entry_point: our_provider.entry_point

access_control:
    - { path: '^/our-provider/(login(/[a-zA-Z]+)?|logout|redirect|callback)', roles: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: '^/', roles: ROLE_USER }

{ path: '^/', roles: ROLE_USER }ユーザーがログインしていない場合、すべてのルートがログインページにリダイレクトされることはわかっています。それは明らかだと思い、言及しませんでした。私が欲しいのは、各フロントエンドの「プロキシルート」を明示的に定義せずに、一致したルートを強制ROLE_USERし、一致しないものを許可することです。IS_AUTHENTICATED_ANONYMOUSLY私の場合、404 Symfony ページはありません。すべてがangular_index_all_unmatched_routesルートに送られ、そこで Angular ルーティング定義が処理するものがあるかどうかを決定するためです。

4

1 に答える 1

0

私はこれを試していないので、既存のセキュリティ/ルート設定security.ymlを推測することはできませんが、IS_AUTHENTICATED_ANONYMOUSLY. Symfonyのドキュメントから:

すべてのユーザー (匿名のユーザーも含む) はこれを持っています - これは、アクセスを保証するために URL をホワイトリストに登録するときに役立ちます - 一部の詳細は、セキュリティの access_control はどのように機能しますか? に記載されています。.

したがって、たとえば、@Securityアノテーションを使用している場合は、次のようにすることができます (テストされていません)。

class AngularController extends Controller {
    /**
     * @Route("/{route}", name="route", requirements={"route" = ".*"})
     * @Template("FrontendBundle::index.html.twig")
     * @Security("has_role('IS_AUTHENTICATED_ANONYMOUSLY')")
     */
    public function angularIndexAction($route) {
        return ['route' => $route];
    }
}

@Securityアノテーションの詳細については、こちらをご覧ください。

お役に立てれば ：）

編集

つまり、 でルートを定義/制限するaccess_controlとsecurity.yml、マッチング プロセスは最初の一致で停止します。明示的に定義する必要があるロール制限パスがいくつかあると仮定し、それらを最初に配置すると、それらが一致するとプロセスが停止します。

それ以外の場合は、 role によって適用されるキャッチオール ルートを追加できるはずですIS_AUTHENTICATED_ANONYMOUSLY。ルートのパス定義は正規表現であるため、^/明示的に定義されていないものは何でもキャッチする必要があります。必ず、制限されたルート定義の後に配置してください。

@Securityこの場合、注釈は必要ありません。

編集 2

クリーンなインスタンスと HTTP BasicAuth を使用してこれをモックしようとしましたが、達成しようとしていたのは次のとおりです。これは、ユース ケースと同様に理解しています。

  • /ルートを使用してバックエンド コントローラーを作成し/api/、HTTP BasicAuth 認証ポップアップをトリガーする
  • /{route}他のすべてに一致し、匿名で認証するルートを持つフロントエンド コントローラーを作成します。

私firewallのaccess_control設定は次のようになります。

security:
    encoders:
        # encoder config here
    providers:
        # provider config here
firewalls:
    dev:
        pattern:  ^/(_(profiler|wdt)|css|images|js)/
        security: false
    secured:
        anonymous: ~
        http_basic: ~

access_control:
    - { path: ^/$,    roles: ROLE_USER }
    - { path: ^/api/, roles: ROLE_USER }
    - { path: ^/,     roles: IS_AUTHENTICATED_ANONYMOUSLY }

アクセス制御パスは正規表現であるため^/$、 と^/は同じではありません。前者は route と完全に一致するだけ/です。/後者は;で始まるすべてのルートに一致します。例: /home、/productsなど/contact

実際、後者は に一致し、匿名で認証しますが、など/apiとは一致しません。これらは明示的に定義され、 に制限されているためです。/api//api/1ROLE_USER

したがって、一般的な考え方は、制限したいルートを明示的に (可能であれば) 正確に一致させ、それらを最初に宣言することです。最後の宣言^/は、通過する他のルートを公然とキャッチする必要があります。

于 2015-03-13T14:25:27.450 に答える