phpdotenv
V5.6.1 (20
Charge automatiquement les variables d'environnement de .env vers getenv() , $_ENV et $_SERVER .
Vous ne devez jamais stocker d'informations d'identification sensibles dans votre code . Le stockage de la configuration dans l'environnement est l'un des principes d'une application à douze facteurs. Tout ce qui est susceptible de changer entre les environnements de déploiement – comme les informations d'identification de base de données ou les informations d'identification de services tiers – doit être extrait du code dans des variables d'environnement.
Fondamentalement, un fichier .env est un moyen simple de charger les variables de configuration personnalisées dont votre application a besoin sans avoir à modifier les fichiers .htaccess ou les hôtes virtuels Apache/nginx. Cela signifie que vous n'aurez pas à modifier de fichiers en dehors du projet et que toutes les variables d'environnement sont toujours définies, quelle que soit la façon dont vous exécutez votre projet - Apache, Nginx, CLI et même le serveur Web intégré de PHP. C'est BEAUCOUP plus facile que toutes les autres façons que vous connaissez de définir des variables d'environnement, et vous allez l'adorer !
php_value aux fichiers .htaccessPHP dotenv est une version PHP du Ruby dotenv original.
L'installation est très simple via Composer :
$ composer require vlucas/phpdotenv ou ajoutez-le manuellement à votre fichier composer.json .
Nous suivons le versioning sémantique, ce qui signifie que des modifications importantes peuvent survenir entre les versions majeures. Nous avons des guides de mise à niveau disponibles pour V2 vers V3, V3 vers V4 et V4 vers V5 disponibles ici.
Le fichier .env est généralement tenu hors du contrôle de version car il peut contenir des clés API et des mots de passe sensibles. Un fichier .env.example distinct est créé avec toutes les variables d'environnement requises définies, à l'exception des variables sensibles, qui sont soit fournies par l'utilisateur pour leurs propres environnements de développement, soit communiquées ailleurs aux collaborateurs du projet. Les collaborateurs du projet copient ensuite indépendamment le fichier .env.example dans un .env local et s'assurent que tous les paramètres sont corrects pour leur environnement local, en remplissant les clés secrètes ou en fournissant leurs propres valeurs si nécessaire. Dans cette utilisation, le fichier .env doit être ajouté au fichier .gitignore du projet afin qu'il ne soit jamais validé par les collaborateurs. Cette utilisation garantit qu'aucun mot de passe ou clé API sensible ne figurera jamais dans l'historique du contrôle de version, ce qui réduit le risque de faille de sécurité et les valeurs de production ne devront jamais être partagées avec tous les collaborateurs du projet.
Ajoutez la configuration de votre application à un fichier .env à la racine de votre projet. Assurez-vous que le fichier .env est ajouté à votre .gitignore afin qu'il ne soit pas archivé dans le code
S3_BUCKET= " dotenv "
SECRET_KEY= " souper_seekret_key " Créez maintenant un fichier nommé .env.example et archivez-le dans le projet. Celui-ci devrait contenir les variables ENV que vous devez définir, mais les valeurs doivent être soit vides, soit remplies de données factices. L’idée est de faire savoir aux gens quelles variables sont requises, mais pas de leur donner les valeurs de production sensibles.
S3_BUCKET= " devbucket "
SECRET_KEY= " abc123 " Vous pouvez ensuite charger .env dans votre application avec :
$ dotenv = Dotenv Dotenv :: createImmutable ( __DIR__ );
$ dotenv -> load (); Pour supprimer l'exception levée lorsqu'il n'y a pas de fichier .env , vous pouvez :
$ dotenv = Dotenv Dotenv :: createImmutable ( __DIR__ );
$ dotenv -> safeLoad (); Vous pouvez éventuellement transmettre un nom de fichier comme deuxième paramètre, si vous souhaitez utiliser autre chose que .env :
$ dotenv = Dotenv Dotenv :: createImmutable ( __DIR__ , ' myconfig ' );
$ dotenv -> load (); Toutes les variables définies sont désormais disponibles dans les super-globales $_ENV et $_SERVER .
$ s3_bucket = $ _ENV [ ' S3_BUCKET ' ];
$ s3_bucket = $ _SERVER [ ' S3_BUCKET ' ]; L'utilisation de getenv() et putenv() est fortement déconseillée car ces fonctions ne sont pas thread-safe, cependant il est toujours possible de demander à PHP dotenv d'utiliser ces fonctions. Au lieu d'appeler Dotenv::createImmutable , on peut appeler Dotenv::createUnsafeImmutable , ce qui ajoutera le PutenvAdapter en coulisses. Vos variables d'environnement seront désormais disponibles via la méthode getenv , ainsi que les super-globales :
$ s3_bucket = getenv ( ' S3_BUCKET ' );
$ s3_bucket = $ _ENV [ ' S3_BUCKET ' ];
$ s3_bucket = $ _SERVER [ ' S3_BUCKET ' ];Il est possible d'imbriquer une variable d'environnement dans une autre, utile pour réduire les répétitions.
Cela se fait en encapsulant une variable d'environnement existante dans ${…} par exemple
BASE_DIR= " /var/webroot/project-root "
CACHE_DIR= " ${BASE_DIR} /cache "
TMP_DIR= " ${BASE_DIR} /tmp " L'immuabilité fait référence à la question de savoir si Dotenv est autorisé à écraser les variables d'environnement existantes. Si vous souhaitez que Dotenv écrase les variables d'environnement existantes, utilisez createMutable au lieu de createImmutable :
$ dotenv = Dotenv Dotenv :: createMutable ( __DIR__ );
$ dotenv -> load (); En coulisses, cela demande au « référentiel » d’autoriser ou non l’immuabilité. Par défaut, le référentiel est configuré pour permettre l'écrasement des valeurs existantes, ce qui est pertinent si l'on appelle la méthode "create" à l'aide de RepositoryBuilder pour construire un référentiel plus personnalisé :
$ repository = Dotenv Repository RepositoryBuilder :: createWithNoAdapters ()
-> addAdapter ( Dotenv Repository Adapter EnvConstAdapter ::class)
-> addWriter ( Dotenv Repository Adapter PutenvAdapter ::class)
-> immutable ()
-> make ();
$ dotenv = Dotenv Dotenv :: create ( $ repository , __DIR__ );
$ dotenv -> load (); L'exemple ci-dessus écrira les valeurs chargées dans $_ENV et putenv , mais lors de l'interpolation des variables d'environnement, nous ne lirons que $_ENV . De plus, il ne remplacera jamais les variables déjà définies avant le chargement du fichier.
Au moyen d'un autre exemple, on peut également spécifier un ensemble de variables à autoriser. Autrement dit, seules les variables de la liste verte seront chargées :
$ repository = Dotenv Repository RepositoryBuilder :: createWithDefaultAdapters ()
-> allowList ([ ' FOO ' , ' BAR ' ])
-> make ();
$ dotenv = Dotenv Dotenv :: create ( $ repository , __DIR__ );
$ dotenv -> load ();PHP dotenv a une fonctionnalité de validation intégrée, notamment pour renforcer la présence d'une variable d'environnement. Ceci est particulièrement utile pour informer les utilisateurs des variables obligatoires explicites sans lesquelles votre application ne fonctionnera pas.
Vous pouvez utiliser une seule chaîne :
$ dotenv -> required ( ' DATABASE_DSN ' );Ou un tableau de chaînes :
$ dotenv -> required ([ ' DB_HOST ' , ' DB_NAME ' , ' DB_USER ' , ' DB_PASS ' ]); Si des variables ENV sont manquantes, Dotenv lancera une RuntimeException comme celle-ci :
One or more environment variables failed assertions: DATABASE_DSN is missing
Au-delà de la simple nécessité de définir une variable, vous devrez peut-être également vous assurer que la variable n'est pas vide :
$ dotenv -> required ( ' DATABASE_DSN ' )-> notEmpty ();Si la variable d'environnement est vide, vous obtiendrez une exception :
One or more environment variables failed assertions: DATABASE_DSN is empty
Vous devrez peut-être également vous assurer que la variable a une valeur entière. Vous pouvez procéder comme suit :
$ dotenv -> required ( ' FOO ' )-> isInteger ();Si la variable d'environnement n'est pas un entier, vous obtiendrez une exception :
One or more environment variables failed assertions: FOO is not an integer.
On peut vouloir appliquer des règles de validation uniquement lorsqu'une variable est définie. Nous soutenons également ceci :
$ dotenv -> ifPresent ( ' FOO ' )-> isInteger ();Vous devrez peut-être vous assurer qu'une variable est sous la forme d'un booléen, en acceptant « vrai », « faux », « activé », « 1 », « oui », « désactivé », « 0 » et « non ». Vous pouvez procéder comme suit :
$ dotenv -> required ( ' FOO ' )-> isBoolean ();Si la variable d'environnement n'est pas booléenne, vous obtiendrez une exception :
One or more environment variables failed assertions: FOO is not a boolean.
De même, on peut écrire :
$ dotenv -> ifPresent ( ' FOO ' )-> isBoolean ();Il est également possible de définir un ensemble de valeurs que doit être votre variable d'environnement. Ceci est particulièrement utile dans les situations où seule une poignée d’options ou de pilotes sont réellement pris en charge par votre code :
$ dotenv -> required ( ' SESSION_STORE ' )-> allowedValues ([ ' Filesystem ' , ' Memcached ' ]);Si la variable d'environnement ne figurait pas dans cette liste de valeurs autorisées, vous obtiendriez une exception similaire :
One or more environment variables failed assertions: SESSION_STORE is not an allowed value.
Il est également possible de définir une expression régulière que devrait être votre variable d'environnement.
$ dotenv -> required ( ' FOO ' )-> allowedRegexValues ( ' ([[:lower:]]{3}) ' ); Vous pouvez commenter votre fichier .env en utilisant le caractère # . Par exemple
# this is a comment
VAR= " value " # comment
VAR=value # commentParfois, vous souhaitez simplement analyser le fichier et résoudre les variables d'environnement imbriquées, en nous donnant une chaîne, et vous faire renvoyer un tableau. Bien que cela soit déjà possible, c'est un peu compliqué, c'est pourquoi nous avons fourni un moyen direct de le faire :
// ['FOO' => 'Bar', 'BAZ' => 'Hello Bar']
Dotenv Dotenv :: parse ( " FOO=Bar n BAZ= " Hello $ {FOO} "" );C'est exactement la même chose que :
Dotenv Dotenv :: createArrayBacked ( __DIR__ )-> load ();seulement, au lieu de fournir le répertoire pour trouver le fichier, vous avez directement fourni le contenu du fichier.
Lorsqu'un nouveau développeur clone votre base de code, il aura une étape unique supplémentaire pour copier manuellement le fichier .env.example vers .env et remplir ses propres valeurs (ou obtenir des valeurs sensibles auprès d'un collègue du projet).
Dans certaines configurations de serveur (que l'on trouve le plus souvent dans l'hébergement partagé), PHP peut désactiver les superglobaux comme $_ENV ou $_SERVER . Si ces variables ne sont pas définies, examinez variables_order dans le fichier php.ini . Voir php.net/manual/en/ini.core.php#ini.variables-order.
Si vous découvrez une vulnérabilité de sécurité dans ce package, veuillez envoyer un e-mail à [email protected]. Toutes les vulnérabilités de sécurité seront rapidement corrigées. Vous pouvez consulter notre politique de sécurité complète ici.
PHP dotenv est sous licence BSD à 3 clauses.
Disponible dans le cadre de l’abonnement Tidelift
Les responsables de vlucas/phpdotenv et de milliers d'autres packages travaillent avec Tidelift pour fournir un support commercial et une maintenance pour les dépendances open source que vous utilisez pour créer vos applications. Gagnez du temps, réduisez les risques et améliorez la santé du code, tout en rémunérant les responsables des dépendances exactes que vous utilisez. Apprendre encore plus.
