Heute haben wir eine Empfehlung aus der Technik, die wir in unseren Projekten umsetzen und sicher auch für Andere interessant ist.

Der Shop speichert seine Einstellungen (Zugangsdaten und Konfigurationen) in der Datei config.inc.php. Darin sind sensible Daten enthalten (z.B. Zugangsdaten zur Datenbank). Deshalb soll diese Datei normalerweise nicht in die Versionsverwaltung aufgenommen werden. Nun können darin aber auch Konfigurationseinstellungen enthalten sein können, die aus diversen Gründen gesichert werden sollten.

Um diesen Konflikt zu lösen, sollten sensible projektspezifische Daten nur dynamisch in die config.inc.php eingefügt werden. Ein möglicher Weg hierfür sind die Environment-Variablen. Diese werden global oder projektspezifisch auf dem Server gesetzt und können über $_ENV[‚…‘] in die Shopkonfiguration eingebunden werden.

Für das Setzen der ENV-Variablen gibt es folgende Wege:

• über $ set systemweit
• über EXPORT command z.B. in der .bashrc
• als SetEnv in .htaccess
• mit putenv() in PHP-Scripten
• als .env-Datei und Einbindung über ein PHP-Paket

Die meisten Möglichkeiten haben Vor- und Nachteile. So müssen die ENV-Variablen bei Aufrufen über den Webserver sowie auch bei Aufrufen über CLI (Terminal oder auch Cron-Aufrufe) verfügbar sein. Als unkomplizierte Lösung zeigt sich bislang die Verwendung der .env-Datei in Verbindung mit phpDotEnv.

Für die Einrichtung ist Folgendes auszuführen:

Dem Shopprojekt ist dieses Paket hinzuzufügen (Alternativen mit geänderten Aufrufen sind ebenfalls verfügbar):

composer require vlucas/phpdotenv

Im Shoproot wird die Datei .env mit diesem Inhalt angelegt. Diese Datei (und auch nur diese) wird Sammelbecken solcher sensiblen Daten werden:

### important notes
# use integer 0 or 1 for boolean values instead of false or true

### required
## Database
OXID_CONF_DBHOST="127.0.0.1"
OXID_CONF_DBPORT="3306"
OXID_CONF_DBNAME=""
OXID_CONF_DBUSER="${OXID_CONF_DBNAME}"
OXID_CONF_DBPWD=""

## URL and Paths
OXID_CONF_SHOPURL="https://www.myshop.com"
OXID_CONF_SSLSHOPURL="${OXID_CONF_SHOPURL}"
OXID_CONF_SHOPDIR="/www/htdocs/www.myshop.com.com/source"
OXID_CONF_COMPILEDIR="${OXID_CONF_SHOPDIR}/tmp"

### optional (disable, if unused)
## URL and Paths
OXID_CONF_ADMINSSLURL=""

## MISC
OXID_CONF_DEBUG=0
OXID_CONF_LOGERRORS=1
OXID_CONF_ERRORREPORTING=1
OXID_CONF_DISPLAYERRORS=0
# OXID_CONF_SKIPVIEWUSAGE=0


Die config.inc.php wird gleich in den ersten Zeilen wie folgt erweitert:

require_once __DIR__.DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'vendor'.DIRECTORY_SEPARATOR.'autoload.php';
$dotenv = \Dotenv\Dotenv::createImmutable(__DIR__.'/..');
$dotenv->load();
$dotenv->required([
'OXID_CONF_DBHOST', 'OXID_CONF_DBPORT', 'OXID_CONF_DBNAME',
'OXID_CONF_DBUSER', 'OXID_CONF_DBPWD', 'OXID_CONF_SHOPURL',
'OXID_CONF_SHOPDIR', 'OXID_CONF_COMPILEDIR'
])->notEmpty();


Alle weiteren Zeilen, die sensible oder installationsabhängige Daten enthalten, werden beispielhaft so umgebaut. Dies sollte für alle oben genannten Variablen durchgeführt werden:

// Database connection information
$this->dbType = 'pdo_mysql';
$this->dbHost = $_ENV['OXID_CONF_DBHOST']; // database host name
$this->dbPort = $_ENV['OXID_CONF_DBPORT']; // tcp port to which the database is bound
$this->dbName = $_ENV['OXID_CONF_DBNAME']; // database name
$this->dbUser = $_ENV['OXID_CONF_DBUSER']; // database user name
$this->dbPwd = $_ENV['OXID_CONF_DBPWD']; // database user password
$this->sShopURL = $_ENV['OXID_CONF_SHOPURL']; // eShop base url, required
$this->sSSLShopURL = $_ENV['OXID_CONF_SSLSHOPURL']; // eShop SSL url, optional
$this->sAdminSSLURL = $_ENV['OXID_CONF_ADMINSSLURL']; // eShop Admin SSL url, optional
$this->sShopDir = $_ENV['OXID_CONF_SHOPDIR'];
$this->sCompileDir = $_ENV['OXID_CONF_COMPILEDIR'];


Damit ist die Config-Datei ausreichend bereinigt und kann so nun ins Repository übernommen werden. Die .env-Datei sollte die Berechtigung 400 erhalten und darf nicht in die Versionsverwaltung aufgenommen werden. Dies kann durch einen Eintrag in der .gitignore sichergestellt werden. Als Kopiervorlage empfiehlt sich, statt dessen eine bereinigte .env.example im Repo abzulegen.

Sofern nötig, können auch für andere Fälle ENV-Variablen abgelegt werden. Denkbar ist dies z.B. für Lizenzschlüssel, die scriptbasiert im Shop hinterlegt werden.

Diese Integration ergänzt die bestehenden ENV-Variablen, sofern diese bisher nicht gesetzt wurden. Existieren diese schon aus anderen Quellen (z.B. .htaccess), bleiben diese unangetastet. Der Vorteil ergibt sich daraus, dass serverabhängig andere Einstellungen vorgegeben werden können, ohne dass die .env-Settings diese überschreiben dürfen.