Les variables d'environnement de Laravel fuient entre les applications quand elles s'appellent par GuzzleHttp
J'ai deux applications Laravel 5.2 (appelons-les A et B) sur ma machine locale, toutes deux configurées sur deux postes virtuels différents sur mon serveur de développement local Apache 2.4.
les deux applications s'appellent parfois par GuzzleHttp.
à un moment, j'ai voulu utiliser le cryptage et j'ai commencé à obtenir des exceptions "mac n'est pas valide" du Crypteur de Laravel.
en étudiant la question, j'ai constaté que lorsque app a appelle app b, app b obtient soudainement la clé de cryptage (app.la clé) à partir de l'app Un! Cela provoque le cryptage de casser parce que les valeurs sur l'application b où crypté en utilisant la clé de cryptage B de l'application.
pendant le débogage, j'ai trouvé que la bibliothèque Dotenv a une logique pour garder les variables existantes si elles sont définies. J'ai trouvé que $_ENV et $_SERVER n'ont pas de variables divulguées, mais getenv() a eux!
je suis un peu confus parce que PHP putenv dit:
La variable d'environnement ne existent pour la durée de la demande actuelle.
il semble que, si pendant la requête courante je lance une autre requête via GuzzleHttp, les variables définies par Dotenv dans un putenv() deviennent soudainement disponibles dans l'application B qui est demandée par GuzzleHttp!
je comprends que ce ne sera pas un problème sur les serveurs de production où le cache de config sera utilisé à la place de Dotenv et que très probablement les deux applications fonctionneront sur des serveurs Apache différents, mais ce comportement est briser mon processus de développement.
comment configurer Laravel ou GuzzleHttp ou Apache ou PHP pour empêcher cela putenv() fuite de l'application a vers l'application b?
1 réponses
Le problème est que vous utilisez une instance partagée de PHP, de sorte que lorsque l'une des applications définit une variable d'environnement qui est partagée avec l'autre application. Je crois que phpdotenv les traite comme immuables, donc une fois qu'ils sont définis, l'autre application ne peut pas les outrepasser.
mod_php (que je présume que vous utilisez puisque vous avez mentionné apache) fournit essentiellement un interpréteur php à l'intérieur de chaque processus apache. Un processus apache sera partagé entre tous vos vhosts donc pourquoi vous êtes avoir ce problème. Vous obtiendriez aussi le même problème si vous exécutiez Nginx et php-fpm, cependant c'est plus facile à résoudre si vous exécutiez la dernière pile de logiciels.
Malheureusement, un port ne peut être lié à un processus. Donc la seule façon de rester avec mod_php et apache est de placer vos vhosts sur des numéros de port séparés, ce qui signifie que vous devrez placer le numéro de port d'au moins un d'entre eux dans l'url lorsque vous y accéderez. Je n'utilise plus vraiment apache donc je ne peux pas te donner détails spécifiques sur le fait de le faire, il pourrait s'agir simplement de configurer différents ports dans votre config vhost et apache le fera, mais je devrai vous déférer aussi google.
si vous exécutiez Nginx / php-fpm, ce serait probablement juste un cas de créer une deuxième config de processus php-fpm tournant sur un port ou une socket différent et pointant le second serveur virtuel sur cette instance php et vous partez.
En résumé, vous avez quelques solutions:
- restez avec apache et mod_php, et passer le reste de la semaine googler comment faire ce que j'ai dit.
- Lancez php comme un module cgi sur apache vous donnera alors la flexibilité dont vous avez besoin (cela s'apparente à l'utilisation de Nginx/php-fpm mais sans changer le logiciel de votre serveur web).
- arrêtez d'utiliser phpdotenv et trouvez une approche alternative (telle que charger votre configuration dans htaccess ou à l'intérieur du serveur virtuel pour qu'il soit disponible sous $_ENV ou $_SERVER keys)
- installer une pile dev Cela inclut nginx / php-fpm et il devrait être facilement soluble en créant deux processus php
- utiliser des machines virtuelles (peut-être regarder Vagabond ou docker) .
Désolé je n'ai pas de meilleures nouvelles, mais malheureusement votre WAMP stack est juste un peu trop restrictive hors de la boîte.