「.env ファイルは（中略）本番環境での使用は推奨されません。 」についての話です。
EC-CUBE 4 系では環境ごとの設定を行うために .env というファイルが使われるようになりましたが、以前からこの .env の扱いについて個人的に疑問を感じていました。詳細は後述しますが、この .env は本番環境での使用が推奨されていないにも関わらずその注意喚起が「開発者向けドキュメント」でしかされていないのです。
先日、Twitter でこれに関するツイートが流れてきたので QT させていただきました。
これ前から疑問なんだけど使っちゃいけないのなら何でデフォルトで.env使うようにしてるんだろうって話だしベストプラクティスの説明も無かったと思う。DBのパスワードの扱いに関しては記事が山のようにあるけど.bashrcにも絶対に書かないかな https://t.co/G2lnoflaRL
— Y (@mattintosh4) 2021年3月31日
これに関して下記の返信をいただきました。
Apache2.4 の mod_access_compat が無効になっているサーバーで .env が公開されてしまった事例を知ってますし、https://t.co/5tJ6kuLLxe
— 🍣大河内健太郎🕊💉 (@nanasess) 2021年3月31日
.htaccess の修正をミスって不用意に公開されてしまうことを防ぐために、複数の対策をしておくのが良いかと
Apache2.4 の mod_access_compat が無効になっているサーバーで .env が公開されてしまった事例を知ってます
とのことで、なぜそれが .env を使ってはいけないということになるのか一瞬「？」となりましたが、なんとなく下記のようなことが起きたのだろうと思いました。以下は私の推測です。
EC-CUBE 4 系のシステム要件は Apache は 2.4.x となっており、Apache 2.4 では Require ディレクティブに切り替わっていますが EC-CUBE のソースコードの .htaccess は 4.0.5 の段階でも Order、Allow、Deny ディレクティブが使われています。これらは mod_access_compat 無効な環境では .htaccess 内の Order ディレクティブが解釈できないため Apache は 500 Internal Server Error となります。
Invalid command 'order', perhaps misspelled or defined by a module not included in the server configuration
このエラーに関しては EC-CUBE ディレクトリ直下の .htaccess を書き換えれば動きます。直下の .htaccess 以外にも下記の場所で Order ディレクティブが使われています。
下記の差分は EC-CUBE 4.0.5 の .htaccess ですが、正規表現が不要と思われる場所で Files ~ が使われており index.php の指定が index{任意の1文字}php に一致するようになってしまっているのでこちらも修正しています。（初期段階から正規表現が正確ではなかったがその後も修正はされていないようです。また、Apache では Files ~ ではなく FileMatch の使用を推奨しているため置き換えています）
--- .htaccess_ 2021-04-03 22:55:56.000000000 +0900 +++ .htaccess 2021-04-03 22:56:26.000000000 +0900 @@ -1,13 +1,11 @@ DirectoryIndex index.php index.html .ht <FilesMatch "^composer|^COPYING|^\.env|^\.maintenance|^Procfile|^app\.json|^gulpfile\.js|^package\.json|^package-lock\.json|web\.config|^Dockerfile|^\.editorconfig|\.(ini|lock|dist|git|sh|bak|swp|env|twig|yml|yaml|dockerignore|sample)$"> - order allow,deny - deny from all + Require all denied </FilesMatch> -<Files ~ "index.php"> - order deny,allow - allow from all +<Files "index.php"> + Require all granted </Files> <IfModule mod_headers.c>
このことを知らない利用者がエラーの内容から「order の行がエラーになってるのでコメントアウトしたら動いたので良しとした」という状態でアクセス制限が機能せず .env が漏洩してしまったのではないかと思われます。
ただ、事故の原因が推測通りの内容であったならば、
- EC-CUBE が
.htaccessで mod_access_compat のディレクティブ（Order、Allow、Deny）を使用している - mod_access_compat が必須であるにも関わらずシステム要件に記載が無い
という部分に問題があると思うので個人的には「.env を使ってはいけない」ことの事例としては微妙かなと感じました。
EC-CUBE に限らず .env は使われていて推測されやすいものです。データベース情報などの機密情報が含まれていて危険なのが予めわかっているはずなので特に気を使って下記のようなディレクティブを用意する方が利用者にとっては良いのではないかと思います。
# .htaccess 編集後は必ず .env が非公開になっているか確認してください <Files ".env*"> Require all denied </Files>
3 系ではデフォルトで EC-CUBE ディレクトリ直下の html ディレクトリをドキュメントルートとしていたためその上の階層にあるシステムに関するファイルには触れられないようになっていました。しかし、4 系では EC-CUBE ディレクトリ直下をドキュメントルートにするようになったため .env のような機密情報が含まれたファイルが漏洩する危険性が高くなっています。
私はインフラ担当なのでアプリケーション担当者さんの作業にはあまり口を出したくないとは思っているのですが、4 系を扱っているアプリケーション担当者さんが非公開というかそこに置くべきではないファイル（例えば README.md など）を配置していたりするのでこれまでに指摘したことが何度かあります。
これは EC-CUBE にきちんとした利用者向けマニュアル（「"開発者向け"ドキュメント」の話ではありません）が用意されていないからではないかと感じることもあります。（OSS だしそこら辺は自己責任という意見もあるとは思いますが）
現行のソースでは FilesMatch の部分でアクセス拒否するパターンを徐々に追加していますが、これにも限界はあるので説明を設けた上で利用者自身に判断してもらった方がいいのではないかと思います。また、既存コードは長くなり読みづらくなりつつあるので「直下に配置されるファイル」と「それ以外のファイル」に分けてもらいたいところでしょうか。以下ざっくりとした例です。（※何らかの操作で追加作成されるようなファイルに関しては考慮していません）
<Files ".env*"> Require all denied </Files> <Files ".git*"> Require all denied </Files> # EC-CUBE ディレクトリ直下に配置されるファイルのうち非公開が推奨されるもの # https://httpd.apache.org/docs/2.4/ja/mod/core.html#filesmatch <FilesMatch "^(\.dockerignore|\.env(\.(dist|install))|COPYING|Dockerfile|composer\.json|composer\.lock|docker-compose\.yml|gulpfile\.js|package(|-lock)\.json|symfony\.lock|web\.config)$"> Require all denied </FilesMatch> # 非公開が推奨される拡張子 # https://httpd.apache.org/docs/2.4/ja/mod/core.html#filesmatch <FilesMatch "\.(?i:bak|dist|ini|lock|sample|sh|sw[uwx][a-z]|twig|ya?ml)$"> Require all denied </FilesMatch> <Files "index.php"> Require all granted </Files>
話を .env に戻して、私が最も気にしているのが「本番で .env を使ってはいけない」というのであれば「ではどうすればいいのか？」ということです。
現時点の EC-CUBE の「開発者向けドキュメント」では下記のように説明されています。
本番環境での .env ファイルの利用について
インストール完了後、インストールディレクトリにデータベースの接続情報等が設定された .env ファイルが生成されます。 .env ファイルは、開発用途での環境変数を設定するためのものであり、本番環境での使用は推奨されません。 本番環境では、環境変数をサーバ設定ファイルに設定することを推奨します。 サーバ設定ファイルに環境変数を設定することにより、環境変数が外部に暴露される危険性が減り、安全に運用できます。
この「本番環境での使用は推奨されません」という文言は EC-CUBE のサイトを一通り確認しましたが「開発者向けドキュメント」にしか記載されておらず、一般向けのページには記載がありませんでした。EC-CUBE デフォルトのインストール状態で .env が作成されるようになっており、その元となる .env.dist にも注意文が無く、Symfony デフォルトと思われる文言で「本番、ステージング、開発で使い分ける〜」のように書いてあります。
This file is a "template" of which env vars needs to be defined in your configuration or in an .env file
Set variables here that may be different on each deployment target of the app, e.g. development, staging, production.
https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration
実際、私が EC-CUBE 関連のプロジェクトで関わったアプリケーションエンジニアさんに本番での .env の使用を禁止しているような人はいませんでした。
EC-CUBE 社が公開しているセキュリティチェックシートも確認してみましたが .env の部分は「公開されているか否か」の確認だけであり、「.env ファイルが存在しない」という確認方法ではありません。対応方法も現状の .htaccess でアクセス制限を行うだけで「.env の使用は推奨されていないためこちらをお読みいただきご対応ください」というような案内もありませんでした。
- ファイル名: security_checklist.xlsx
- 作成日: 2020/06/25, 07:39:47
- 更新日: 2020/12/10, 05:48:30
確認方法
EC-CUBEのURL直下(例: https://example.com/path/to/ec-cube/.env など)に .env ファイルが公開されていないか、ファイルの中身が表示されないことをご確認ください。
対応方法
EC-CUBE をインストールしたフォルダの .htaccess ファイルに以下の内容を追加し、保存してください。
<FilesMatch "^composer|^COPYING|^\.env|^\.maintenance|^Procfile|^app\.json|^gulpfile\.js|^package\.json|^package-lock\.json|web\.config|^Dockerfile|\.(ini|lock|dist|git|sh|bak|swp|env|twig|yml|yaml|dockerignore)$">
order allow,deny
deny from all
</FilesMatch>
このことについて「あくまで推奨であり、設定方法については自己責任」という方針なのかもしれませんが、普通に考えれば「本番」というものは「主」や「正」であり、その「本番」で推奨されないのであればその他の環境も合わせるべきではないかと個人的には思います。
.env の扱いについて考えてみる
あまり時間が取れないので少々雑ですがこちらに自分の見解をまとめておきます。
Symfony ではどう考えているのか？
EC-CUBE 4.0.x では Symfony 3.4 を使っているので Symfony 3.4 のドキュメントを見ればいいと思うのですが、どうも EC-CUBE の構造の所々が Symfony 4.x になっていると思われたため Symfony 4.0 と 4.4 のドキュメントも確認してみました。（結局 Symfony の考えはよくわからなかったのですが）
Symfony 3.4 でも 4.x でも環境変数の設定は Web サーバレベル（httpd.conf、.htaccess）で設定することが推奨されていました。
（翻訳は DeepL におまかせしています）
Symfony 3.4
Setting environment variables is generally done at the web server level or in the terminal. If you’re using Apache, nginx or just the console, you can use e.g. one of the following:
https://symfony.com/doc/3.4/configuration/external_parameters.html#environment-variables
環境変数の設定は、一般的にウェブサーバーレベルかターミナルで行います。Apacheやnginxを使用している場合や、コンソールだけの場合は、例えば以下のいずれかを使用します。
Symfony 4.0
During development, you’ll use the .env file to configure your environment variables. On your production server, it is recommended to configure these at the web server level. If you’re using Apache or Nginx, you can use e.g. one of the following:
開発段階では、.envファイルを使って環境変数を設定します。本番サーバーでは、Webサーバーレベルでこれらを設定することをお勧めします。ApacheやNginxを使用している場合は、例えば以下のようなものがあります。
Symfony 3.4 と 4.0 の説明で大きく違うのは「コンソール」の文言がなくなっていること。上記の説明の通り DATABASE_URL を Web サーバ側に設定すると、例えば console doctrine:migrations:status を実行しようとしたときに $_SERVER["DATABASE_URL"] を参照しないためデータベースに接続できない問題が起きます。Symfony 3.4 のドキュメントが書かれていた時期に console コマンドで Doctrine 関連の処理が問題なくできたのかどうかはわかりませんが、少なくとも EC-CUBE 4.0.5 では DATABASE_URL を Web サーバレベルで設定すると console コマンドからはデータベースに接続できなくなります。
さらに、Web サーバレベルで設定する際の注意文が記載されています。
Beware that dumping the contents of the $SERVER and $ENV variables or outputting the phpinfo() contents will display the values of the environment variables, exposing sensitive information such as the database credentials.
The values of the env vars are also exposed in the web interface of the Symfony profiler. In practice this shouldn’t be a problem because the web profiler must never be enabled in production.
変数 $SERVER と $ENV の内容をダンプしたり、phpinfo() の内容を出力したりすると、環境変数の値が表示され、データベースの認証情報などの機密情報が公開されてしまうことに注意してください。
環境変数の値は、Symfony プロファイラーの Web インターフェースでも公開されます。本番環境では Web プロファイラーを有効にしてはならないので、実際には問題にならないはずです。
動作として当然そうなるわけですが「注意して」とだけ言われても正直なところどうしていいかわかりません。
「では console コマンドを使う場合はどうするのか？」に関する説明は Symfony のドキュメントからは見つけられませんでした。EC-CUBE ではこの問題への対応として「開発者向けドキュメント」でシェルで環境変数を設定する方法を紹介しているようです。
テキストファイルにデータベースのパスワードを平文で書くことは世間的に推奨されていないものですが、EC-CUBE に限らず PHP ファイルや YAML ファイルに DB のパスワードを平文で書いているので .bashrc や .bash_profile に書いたところで何を今更…という感じはあります。海外の記事では「 /etc/environment に書けばいいよ！」みたいなものもありました（それは流石にどうなんだ）。
なお、新しい Symfony のバージョンでは暗号化する機能が追加されているようですが EC-CUBE 4.0.5 は対応していません。
EC-CUBE で紹介されている方法でもいいとは思うのですが、個人的には複数の場所にデータベースの情報持たせるのはやや抵抗があります。というのは実際の運用ではデータベースの切り替えやメールサーバの切り替えというものが発生します。これによって Web サーバレベルの DATABASE_URL とシェルの DATABASE_URL が異なり、console コマンドによって間違ったマイグレーションやメール配信が行われてしまう可能性が考えられます。
また、VirtualHost を使って Web サーバを共用している場合でも同じようなことが起こり得ます。例えば VirtualHost を使って本番環境と開発環境を分けている場合、アプリケーションはディレクトリや Web サーバレベルで分離していますが、シェルにはそのような機能はありません*1。.env はシェルの文法を用いているため「開発環境では . .env や source .env で .bashrc で設定された環境変数をオーバーライドする」というような運用で環境を切り替えることは可能ですが、そこから本番環境の設定値に戻すには変数の解除か再ログインが推奨されます*2。
*1: 環境毎にログインユーザを分ける場合は除く。
*2: 再読み込みではどちらかでしか定義されていない変数を明確に解除できないため。
このようなことから console コマンドのためにシェルに変数を設定することは利用するサービスによって各々の対応が必要になるため私は良い選択だとは思いません。
シェルに関してはアプリケーションエンジニアさんがあまり詳しくないこともあるため、アプリケーション側だけでなんとかならないものだろうかと思っています。
.env が危険なのは本番に限った話ではない場合もある
「本番で推奨されないものを他の環境で使用しても問題ないのか？」という疑問があったので考えてみました。
まず、環境ごとに DATABASE_URL などが含まれる .env の危険性を考えてみます。
| 環境 | 考えられる.envの危険性 |
|---|---|
| 本番 | 高 |
| ステージング | 低〜高 |
| 開発 | 低〜高 |
| ローカル | 低 |
ステージング環境と開発環境を「低〜高」としているのは、ステージング環境や開発環境に適切なアクセス制限が設けられている場合は「低」となりますが、アクセス制限が設けられていない場合や設定が不適切な場合は「高」にもなる可能性があるからです。
利用しているサービスやコストに制限があり、環境ごとにデータベースサーバが分離できない場合は全環境でデータベースサーバを共用してデータベースのみ分けている場合もあると思います。この状態で各環境の DATABSE_URL が下記のように設定されていたとします。
| 環境 | 設定ファイル | 設定値 |
|---|---|---|
| 本番 | httpd.conf または .htaccess | SetEnv DATABASE_URL mysql://user:password@db/eccube_prod |
| ステージング | .env | DATABASE_URL=mysql://user:password@db/eccube_stg |
| 開発 | .env | DATABASE_URL=mysql://user:password@db/eccube_dev |
この場合、ステージングや開発から .env が漏洩した場合は本番から漏洩したことと同等になります。
Symfony の「本番サーバでは Web サーバレベルで設定することを推奨」という説明は「本番（パブリック）」と「ローカル（プライベート）」の場合は適切な説明かもしれませんが、ステージングや開発からも漏洩の可能性があることを考えると「外部に公開されている環境での .env の使用は推奨されない」というのが適切な説明ではないかと思います。
アプリケーション側だけでうまく運用できないのか？
Symfony のドキュメントでは .env 以外に環境（prod や dev）を設定する方法として、3.4 では config_<env>.yml、4.0 では config/packages/<env>/*.yaml 等があると説明されています。それぞれ「How to Master and Create new Environments」で説明されています。
- https://symfony.com/doc/3.4/configuration/environments.html
- https://symfony.com/doc/4.0/configuration/environments.html
「The Symfony Framework Best Practices」では現時点では Symfony 4.3 以降のドキュメントしか存在しないようですが、services_<env>.yaml についても説明されています。
「Configuring Symfony」では Symfony 4.4 で config/packages/<env> や services_<env>.yaml についてもう少し詳しく説明されています。
他にも記載されているページはあるかもしれませんが、Symfony のドキュメント自体がメンテナンスされていたりされていなかったりで探すのが非常に面倒なため上記のページに絞ります。（EC-CUBE で使われていると言われる Symfony のバージョンもよくわからない）
https://symfony.com/doc/4.4/configuration.html#configuration-environments によると Symfony には dev、prod 、test という風に環境を分類して読み込まれるファイルの順番が決まっており、順に値を上書きできるとのこと。
A typical Symfony application begins with three environments:
dev(for local development),prod(for production servers) andtest(for automated tests). When running the application, Symfony loads the configuration files in this order (the last files can override the values set in the previous ones):
読み込まれる順については下記の通り。
config/packages/*.yaml(and*.xmland*.phpfiles too);config/packages/<environment-name>/*.yaml(and*.xmland*.phpfiles too);config/services.yaml(andservices.xmlandservices.phpfiles too);config/services_<environment-name>.yaml(andservices_<environment-name>.xmlandservices_<environment-name>.phpfiles too).
この動作を信じれば環境毎に異なる値については .env を使わずとも config/packages/<env> や config/services_<env>.yaml で持たせることができるはずです。実際、EC-CUBE 4.0.5 ではデフォルトで app/config/services_dev.yaml が配置されていて dev 時固有の設定が書かれています。
EC-CUBE 4.0.5 インストール直後の .env は下記のようになっています。（ホスト名とかは適当です）
APP_ENV=prod APP_DEBUG=0 DATABASE_URL=mysql://eccube:password@db/eccube DATABASE_SERVER_VERSION=5.7.32-log MAILER_URL=smtp://mail:25 ECCUBE_AUTH_MAGIC=MGZkOTIzY2EwNDkyNjM0YWM3NzVmNWY5 ECCUBE_ADMIN_ALLOW_HOSTS=[] ECCUBE_FORCE_SSL=false ECCUBE_ADMIN_ROUTE=adm1n ECCUBE_COOKIE_PATH=/ ECCUBE_TEMPLATE_CODE=default ECCUBE_LOCALE=ja
各項目を「環境毎に異なるか共通しているか」「漏洩した際に影響があるか」について考えてみます。（これについてはざっくりとした見解です）
| 変数 | 共通? | 影響? |
|---|---|---|
| APP_ENV | no | no |
| APP_DEBUG | no | no |
| DATABASE_URL | no | yes |
| DATABASE_SERVER_VERSION | yes and no | no |
| MAILER_URL | yes and no | yes |
| ECCUBE_AUTH_MAGIC | yes and no | yes |
| ECCUBE_ADMIN_ALLOW_HOSTS | yes and no | yes and no |
| ECCUBE_FORCE_SSL | yes and no | no |
| ECUBEE_ADMIN_ROUTE | yes and no | yes and no |
| ECCUBE_COOKIE_PATH | yes and no | no |
| ECCUBE_TEMPLATE_CODE | yes and no | no |
| ECCUBE_LOCALE | yes and no | no |
とりあえず漏洩すると特に影響があるのは下記の 3 つです。ECCUBE_AUTH_MAGIC に関してはデータベースの情報と組み合わせたときに問題になるため影響ありとしています。ECCUBE_ADMIN_ALLOW_HOSTS や ECCUBE_ADMIN_ROUTE に関しては仮に漏洩したとしても認証で守られているのでここでは除外します。
DATABASE_URLMAILER_URLECCUBE_AUTH_MAGIC
以下、対象を DATABASE_URL に絞ります。
ECCUBE 4.0.5 インストール直後で DATABASE_URL が使われているファイルは下記の 2 箇所です。
1 parameters: 2 # Adds a fallback DATABASE_URL if the env var is not set. 3 # This allows you to run cache:warmup even if your 4 # environment variables are not available yet. 5 # You should not need to change this value. 6 env(DATABASE_URL): '' 7 env(DATABASE_SERVER_VERSION): ~
17 # EC-CUBE parameter 18 eccube_database_url: '%env(DATABASE_URL)%' 19 eccube_mailer_url: '%env(MAILER_URL)%' 20 eccube_admin_route: '%env(ECCUBE_ADMIN_ROUTE)%' 21 eccube_user_data_route: '%env(ECCUBE_USER_DATA_ROUTE)%' 22 eccube_admin_allow_hosts: '%env(json:ECCUBE_ADMIN_ALLOW_HOSTS)%' 23 eccube_force_ssl: '%env(bool:ECCUBE_FORCE_SSL)%'
doctrine.yaml では「フォールバック用として設定する」と説明されており、デフォルトでは DATABASE_URL は空に設定されています。eccube.yaml では %env(DATABASE_URL)% によって環境変数から取得するようになっています。
上記の 2 箇所以外で DATABASE_URL は使われておらず、定義もされていないため動作としては .env や Web サーバの環境変数などから DATABASE_URL を取得することになります。
doctrine.yaml や https://symfony.com/doc/4.0/configuration/external_parameters.html#environment-variables を見ればわかりますが、env() は参照しかできないわけではなく、YAML 内で環境変数のデフォルト値を設定することができるようになっています。
parameters: env(DATABASE_HOST): localhost
EC-CUBE 4.0.5 でも eccube.yaml 内で env() を使って環境変数のデフォルト値を定義しています。
1 parameters: 2 # EC-CUBE default env parameters 3 env(ECCUBE_ADMIN_ROUTE): 'admin' 4 env(ECCUBE_USER_DATA_ROUTE): 'user_data' 5 env(ECCUBE_ADMIN_ALLOW_HOSTS): '[]' 6 env(ECCUBE_FORCE_SSL): false 7 env(ECCUBE_TEMPLATE_CODE): 'default' 8 env(ECCUBE_AUTH_MAGIC): '<change.me>' 9 env(ECCUBE_COOKIE_NAME): 'eccube' 10 env(ECCUBE_COOKIE_PATH): '/' 11 env(ECCUBE_COOKIE_LIFETIME): 0 12 env(ECCUBE_GC_MAXLIFETIME): 1440 13 env(ECCUBE_PACKAGE_API_URL): 'https://package-api.ec-cube.net' 14 env(ECCUBE_OWNERS_STORE_URL): 'https://www.ec-cube.net' 15 env(ECCUBE_MAINTENANCE_FILE_PATH): '%kernel.project_dir%/.maintenance'
長くなってきたのでここからは若干端折って書きますが、先の Symfony の説明の通り packages/*.yaml の情報は services.yaml や services_<env>.yaml で上書きができるので、.env に書いたり Web サーバの環境変数に設定する必要は無いと考えられます。
ただし、console コマンドはまず環境変数からチェックし、環境変数が設定されていないければ .env を参照するようになっています。APP_ENV の値は外部に漏れても特に問題ないので export APP_ENV=prod や APP_ENV=prod php bin/console と叩かなくて済むように APP_ENV は .env に書いておいていいと思います。
<?php : 中略 : if (!isset($_SERVER['APP_ENV'])) { if (file_exists(__DIR__.'/../.env')) { (new Dotenv())->load(__DIR__.'/../.env'); } else { (new Dotenv())->load(__DIR__.'/../.env.install'); } } $input = new ArgvInput(); $env = $input->getParameterOption(['--env', '-e'], $_SERVER['APP_ENV'] ?? 'dev');
これらのことをまとめると機密情報は YAML で管理し、それ以外の項目は .env で管理できそうです。
仮に「ECCUBE_AUTH_MAGIC は全環境で共通」、「services_<env>.yaml は Git で管理されていない」という条件で環境別の構成例を考えると下記のようになります。本番とステージングで services_prod.yaml の名前は同じですが中の値は異なります。DATABASE_SERVER_VERSION は DATABASE_URL とセットということにしています。同一の変数がある場合は右から順（services.yaml → services_<env>.yaml → .env）にオーバーライドされていきます。
services_<env>.yaml の設定についての話なので ECCUBE_AUTH_MAGIC をどこに書くかはここではあまり深く考える必要はありません。
| 環境 | .env | services_<env>.yaml | services.yaml OR eccube.yaml |
|---|---|---|---|
| 本番 | APP_ENV=prod APP_DEBUG=0 |
services_prod.yaml ・DATABASE_URL ・DATABASE_SERVER_VERSION ・MAILER_URL |
ECCUBE_AUTH_MAGIC |
| ステージング | APP_ENV=prod APP_DEBUG=1 |
services_prod.yaml ・DATABASE_URL ・DATABASE_SERVER_VERSION ・MAILER_URL |
ECCUBE_AUTH_MAGIC |
| 開発 | APP_ENV=dev APP_DEBUG=1 |
services_dev.yaml ・DATABASE_URL ・DATABASE_SERVER_VERSION ・MAILER_URL |
ECCUBE_AUTH_MAGIC |
| ローカル | APP_ENV=dev APP_DEBUG=1 DATABASE_URL DATABASE_SERVER_VERSION MAILER_URL |
配置しない | ECCUBE_AUTH_MAGIC |
各 YAML ファイル例は下記の通りです。
parameters: env(DATABASE_URL): mysql://eccube:password@db_prod/eccube_prod env(DATABASE_SERVER_VERSION): 5.7.32-log env(MAILER_URL): smtp://mail_prod:25
parameters: env(DATABASE_URL): mysql://eccube:password@db_stg/eccube_stg env(DATABASE_SERVER_VERSION): 5.7.32-log env(MAILER_URL): smtp://mail_stg:25
parameters: env(DATABASE_URL): mysql://eccube:password@db_dev/eccube_dev env(DATABASE_SERVER_VERSION): 5.7.32-log env(MAILER_URL): smtp://mail_dev:25 services: # 開発時はエラーページを表示しない Eccube\EventListener\ExceptionListener: autoconfigure: false
services: # 開発時はエラーページを表示しない Eccube\EventListener\ExceptionListener: autoconfigure: false
この構成であれば
.envに機密情報を書く必要が無いphpinfo()に情報が出ない- Symfony のプロファイラーに情報が出ない
consoleコマンドがそのまま実行できる.envのAPP_ENVで誤った環境（本番でdev等）を設定していてもエラーで止まる- テンプレートの指定、IP 制限も管理画面から設定できる
というのは一応手元の環境で確認できました。（MAILER_URL も同様に設定しましたが特に問題はありませんでした）
.env を使用しているのは phpunit で必要になるからという情報も見かけたのですが phpunit でのテストはしていません。
長くなったのでこの辺で。
