symfony httpユーザ認証なしのdev環境の基本認証

Question

私はファイアウォール、ユーザプロバイダ、フォーム経由のログイン（FOSUserBundle）、カスタムトークン認証（アプリケーション用）、さらにはHTTP基本認証アプリケーションのもちろん、それらのうちの1つだけが一度に使用されます。特定の領域は、それらのプロバイダに接続する異なるファイアウォールによって保護されます。これは巨大なセキュリティホールであるとしてsecurity.yml

security: 

    encoders: 
     FOS\UserBundle\Model\UserInterface: sha512 

    providers: 
     authentication_provider: 
      entity: 
       class: MyAppBundle:User 
       property: apiKey 
     fos_userbundle: 
      id: fos_user.user_provider.username 

... 

の

エキスは、通常、ライブシステムにはapp_dev.phpはありません。しかし、必要に応じてライブシステムのデバッグを行うのにも最適な方法です。私が持っていたアイデアは、追加のhttp基本認証で開発環境を保護することでした。この方法では、開発環境はまだ安全ですが、必要なときにアクセスできます。

残念ながら、http基本認証を一般的なサイトに追加してログインすると、ユーザーはSymfonyアプリケーションで認証されるため、動作しませんでした。これは当然のことではありませんが、アプリケーションはフォームのログインユーザーと基本的な認証ユーザーとを区別することができないため、アイデアのための認証を行うことはできませんが、ユーザーの種類を区別できますこれはホールアプリケーションでチェックする必要があるため追加したくない複雑なレイヤーになります）。

私の質問は、認証部分を持たないSymfony固有のhttp基本認証を持つことができるかどうかです。したがって、基本認証を完了した後でも、ブラウザはhttp基本認証を送信していますが、あなたはまだ匿名であり、認証されるためにはフォームなどでログインしなければなりません。

EDIT：これはApacheのようなサーバー設定でSymfonyの外でこれを設定する方法があることを知っていますが、私はSymfonyの解決策を探しています（ローカルで変更をホストせずに動作し、 、...）

EDIT 2：深いダイビングの後、私はすべての認証プロセスがある種のトークンを返さなければならないことが分かりました。したがって、プロバイダを上書きしてAnonymus Tokenを返すだけでは簡単ではないかもしれません。

Answer 1

明らかに、ホールセキュリティコンポーネントが構築されているため、検索結果をアーカイブする方法はありません。彼らはすべて、認証されたユーザーがいるという考え方に変わります。それがなければ、関係するコンポーネントは実際には意味をなさない。

トレイルとエラーの時間がたってから、別の解決策が見つかりました。私はこのユースケースのために別の環境debuggingを追加しました。 AppKernel.phpにはdebugフラグがtrueに設定されています。設定およびセキュリティコンポーネントは、次のように変更してdev環境に似：2人のリスナーを

``

config_debugging.yml

imports: 
    - { resource: config.yml } 
    - { resource: security_debugging.yml } 
    - ... 

services: 
    my.debugging.exception_listener: 
     class: My\Bundle\AppBundle\EventListener\DebuggingExceptionListener 
     tags: 
      - { name: kernel.event_listener, event: kernel.exception } 
    my.debugging.access_listener: 
     class: My\Bundle\AppBundle\EventListener\DebuggingAccessListener 
     tags: 
      - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest } 
     arguments: [ '@security.authorization_checker', '@security.token_storage' ] 

security_debugging.yml

security: 
    firewalls: 
     app_resources: 
      pattern: ^/(_(profiler|wdt)|css|images|js)/ 
      security: false 
     ... 
     main: 
      pattern: ^/ 
      http_basic: 
       provider: fos_userbundle 


    access_control: 
     - { path: ^/admin/, role: ROLE_ADMIN } 
     - { path: ^/, role: ROLE_DEBUGGING } 

    role_hierarchy: 
     ROLE_ADMIN:   [ROLE_USER,ROLE_DEBUGGING,ROLE_SONATA_ADMIN] 
     ROLE_SUPER_ADMIN: ROLE_ADMIN 

をチェックするためにあります右の役割ROLE_DEBUGGING。すべての管理者は常にログインできるようになり、特定のユーザーをデバッグする際には、特定の役割が設定されている必要があります。

DebuggingExceptionListener.php

... 
public function onKernelException(GetResponseForExceptionEvent $event) 
{ 
    // You get the exception object from the received event 
    $exception = $event->getException(); 

    if ($exception instanceof AccessDeniedHttpException) { 
     $event->setResponse(new RedirectResponse('/')); 
    } 
} 
... 

DebuggingAccessListener.php

... 
public function onKernelRequest(GetResponseEvent $event) 
{ 
    if (!$event->isMasterRequest()) { 
     return; 
    } 

    if ($this->tokenStorage->getToken() === null) { 
     return; 
    } 

    if ($this->authorizationChecker->isGranted('ROLE_DEBUGGING')) { 
     return; 
    } 

    $event->setResponse(new RedirectResponse('/')); 
} 
... 

それはまだログインで固定ほぼ穴のアプリケーションをチェックすることができますこの方法です。通常のログインコンポーネントやAccessDeniedHttpExceptionsを含むすべてのコンポーネントをデバッグすることはできません。しかし、今のところそれが私が思いつく最高の解決策です。私はまだそこに良い解決策があることを願っています。