2016-12-07 3 views
0

私はsymfony3プロジェクトを持っています。私は完全に独立したSonata管理バンドルをメインアプリケーションから望みます。主なアプリケーションとソナタユーザーは、決して交差しない異なるエンティティです。また、すべてのセキュリティ設定は独立しており、異なっています。さらに将来的には別の管理サブシステムがあります。アプリケーションの別の側面については現在のものと完全に異なります。別のsecurity.ymlファイル/セキュリティ設定の使い方は?

異なる環境やカーネルのオーバーライド(this methodics)を考え、環境ごとのセキュリティ設定を指定する方法(正しいアプローチであり、フレームワークを爆破しない場合)、またはカーネルを無効にすることで選択可能にする方法を知る必要があります。または、あなたがこれを行うために知っているアプローチは何でも。

My symfonyのバージョンは3.1です。

答えて

2

ドキュメントHow to Master and Create new Environmentsで説明するように、既存のproddevtestのものに加えて、新しい環境を作成することができます。これにより、新しい構成ファイル(config_[your_new_environment].yml)にアクセスできるようになり、ファイルをimportsステートメントに読み込み、デフォルト値を上書きすることができます。

例:お使いの場合には

// config_sonata.yml 

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

しかし、私は最初のメインsecurity.ymlファイルの一部として別のファイアウォールを使用して調査します。異なるアプリケーションで保護したいURLが重複しない場合は、単にadd more firewallsuser providersとすることができます。これにより、すべてのニーズをカバーし、すべてを1か所に収めることができます。

+0

ありがとうございます。実際に私の設定ファイルのsecurity.ymlステートメントをインポートし、それが別の方法で読み込まれていると思った私の失敗。可能であれば、私は1つのsecurity.ymlを使用します。必要であれば、それを分けるのは簡単です。私は環境ごとに異なるセキュリティ設定を使用することが、正しい、サポートされたアプローチだと考えています。 Btwあなたはこれまで様々なセキュリティ設定でプロジェクトを設定しましたか?あなたの経験にこれに問題はありますか? – Arkemlar

+0

いいえ環境単位のセキュリティファイルを使用する必要はありませんでした。重複するURLは決してないので、すべてが標準のセキュリティファイルで処理されます。しかし、それが起こった場合、私は別のアプリケーションを作成すると思います。そして、それらのアプリケーション間で共有されるコードがあれば、それをすべてバンドルに入れます。 私は複数の環境での主な問題はそれほど標準的ではないということです。なぜそれをやったのか知っていますが、新しい開発者がプロ​​ジェクトに飛び込んでいくのは明らかです。 – PapyDanone

+0

さて、環境の分離には、管理セクションのカーネルにソナタバンドルをロードするような明白な理由があります。また、2つの管理バックエンドとメインアプリケーションを処理するのに必要な複雑な設定とセキュリティ設定。 – Arkemlar

関連する問題