以下の内容はhttps://mattintosh-note.jp/entry/20210404/1617538511より取得しました。

EC-CUBE 4系の.envの扱いについての話

EC-CUBE Apache

「.env ファイルは（中略）本番環境での使用は推奨されません。 」についての話です。

EC-CUBE 4 系では環境ごとの設定を行うために .env というファイルが使われるようになりましたが、以前からこの .env の扱いについて個人的に疑問を感じていました。詳細は後述しますが、この .env は本番環境での使用が推奨されていないにも関わらずその注意喚起が「開発者向けドキュメント」でしかされていないのです。

先日、Twitter でこれに関するツイートが流れてきたので QT させていただきました。

これに関して下記の返信をいただきました。

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 の部分でアクセス拒否するパターンを徐々に追加していますが、これにも限界はあるので説明を設けた上で利用者自身に判断してもらった方がいいのではないかと思います。また、既存コードは長くなり読みづらくなりつつあるので「直下に配置されるファイル」と「それ以外のファイル」に分けてもらいたいところでしょうか。以下ざっくりとした例です。（※何らかの操作で追加作成されるようなファイルに関しては考慮していません）

.htaccess

<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 ファイルは、開発用途での環境変数を設定するためのものであり、本番環境での使用は推奨されません。 本番環境では、環境変数をサーバ設定ファイルに設定することを推奨します。 サーバ設定ファイルに環境変数を設定することにより、環境変数が外部に暴露される危険性が減り、安全に運用できます。

https://doc4.ec-cube.net/quickstart_install/dotenv

この「本番環境での使用は推奨されません」という文言は 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:

https://symfony.com/doc/4.0/configuration/external_parameters.html#configuring-environment-variables-in-production

開発段階では、.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」で説明されています。

「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) and test (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):

読み込まれる順については下記の通り。

  1. config/packages/*.yaml (and *.xml and *.php files too);
  2. config/packages/<environment-name>/*.yaml (and *.xml and *.php files too);
  3. config/services.yaml (and services.xml and services.php files too);
  4. config/services_<environment-name>.yaml (and services_<environment-name>.xml and services_<environment-name>.php files 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_URL
  • MAILER_URL
  • ECCUBE_AUTH_MAGIC

以下、対象を DATABASE_URL に絞ります。

ECCUBE 4.0.5 インストール直後で DATABASE_URL が使われているファイルは下記の 2 箇所です。

EC-CUBE 4.0.5: app/config/eccube/packages/doctrine.yaml

     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): ~

EC-CUBE 4.0.5: app/config/eccube/packages/eccube.yaml

    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 内で環境変数のデフォルト値を設定することができるようになっています。

env() の使用例

parameters:
    env(DATABASE_HOST): localhost

EC-CUBE 4.0.5 でも eccube.yaml 内で env() を使って環境変数のデフォルト値を定義しています。

app/config/packages/eccube.yaml

     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 に書いておいていいと思います。

EC-CUBE 4.0.5: bin/console

<?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 ファイル例は下記の通りです。

本番: app/config/eccube/services_prod.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

ステージング: app/config/eccube/services_prod.yaml

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

開発: app/config/eccube/services_dev.yaml

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

ローカル: app/config/eccube/services_dev.yaml（未編集）

services:
    # 開発時はエラーページを表示しない
    Eccube\EventListener\ExceptionListener:
        autoconfigure: false

この構成であれば

  • .env に機密情報を書く必要が無い
  • phpinfo() に情報が出ない
  • Symfony のプロファイラーに情報が出ない
  • console コマンドがそのまま実行できる
  • .env の APP_ENV で誤った環境（本番で dev 等）を設定していてもエラーで止まる
  • テンプレートの指定、IP 制限も管理画面から設定できる

というのは一応手元の環境で確認できました。（MAILER_URL も同様に設定しましたが特に問題はありませんでした）

.env を使用しているのは phpunit で必要になるからという情報も見かけたのですが phpunit でのテストはしていません。

長くなったのでこの辺で。



以上の内容はhttps://mattintosh-note.jp/entry/20210404/1617538511より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14