Angular 6, dois-je mettre des variables d'environnement secrètes dans le fichier environment.ts?

Question

Il y a deux sous-questions:

Dois-je mettre des variables d'environnement secrètes dans environment.ts fichier?
La cale variable process a disparu. Si je l'utilise, tsc générera une erreur: Cannot find name 'process'.

Voici mon truc:

À propos de Q1: Je ne pense pas que mettre des variables d'environnement secrètes dans le fichier environment.ts soit correct. Parce que ces fichiers seront une gestion de code source Push, comme GitHub, gitlab, bitbucket. Ce n'est pas prudent. Je pense donc que les variables d'environnement secrètes doivent être passées par process.env, comme process.env.ACCESS_TOKEN, ou, si vous utilisez docker-compose, devrait mettre les variables d'environnement secrètes dans .env fichier et ajoutez ce fichier à .gitignore fichier.

À propos de Q2: Si j'utilise Heroku pour configurer mes variables d'environnement, cela dépend de la variable process. Maintenant, angular6 se débarrasse de la cale de process, comment puis-je travailler avec Heroku? En outre, l'utilisation de variables d'environnement de passe docker-compose via .env le fichier dépend également de process.

Et si vous utilisez .env fichier pour docker-compose, il y a une nouvelle question: Comment passer des variables du fichier .env au fichier angular6 environment.ts

mise à jour 1:

Voici un cas:

Tout d'abord, il n'y a pas de back-end

J'utilise l'API GitHub et une autre API ouverte, et il existe une variable d'environnement nommée access_token, Si je mets ça dans environment.ts fichier et pousser mon code source frontal vers Github, Github détectera les informations secrètes et me donnera un avertissement, ils disent:

Vous ne devez pas mettre le jeton d'accès GitHub dans votre code source et le pousser pour le repo, afin qu'ils révoquent mon jeton d'accès.

Je veux donc utiliser process.env.ACCESS_TOKEN, mais la cale variable process a disparu dans Angular6, Comment puis-je résoudre ça? Dois-je ajouter environment.ts fichier vers .gitignore fichier ou quoi?

mise à jour 2

Voici un autre cas

Continuez avec la mise à jour 1. Maintenant, j'ajoute docker-compose.yaml et Dockerfile pour exécuter mon application frontale dans le conteneur docker.

Voici le workflow:

Écrivez Dockerfile, exécutez npm run build commande et copie ./build répertoire vers nginx répertoire de fichiers statiques du conteneur docker. le ./build le répertoire contient index.html, bundle.js fichier et ainsi de suite.
Mettez access_token et d'autres variables d'environnement secrètes dans .env fichier.
Courir docker-compose up pour exécuter mon application dans un conteneur docker.

Je pense que ce flux de travail est solide. Pas besoin de service back-end, les variables d'environnement secrètes dans .env et .gitignore contient .env fichier, donc il ne sera pas poussé vers le dépôt Github.

Mais le point clé est que process shim a disparu. Je ne peux pas obtenir de variables d'environnement via process.

mise à jour 3

Je pense que ma question se concentre sur la phase de développement d'applications frontales . Je continue à utiliser le cas ci-dessus pour expliquer.

Pour une production prête, le workflow est le suivant:

Créez un service back-end pour github oauth, lorsque le workflow oauth est terminé. Le service back-end envoie access_token au front-end.
connexion frontale réussie, obtenez le access_token à partir du service principal et stockez-le dans localStorage ou cookie. Pas besoin d'obtenir access_token de process.env

Mais pour la phase de développement, le développement frontal et le développement principal sont séparés pour la situation générale. Ainsi, le frontal ne devrait pas dépendre du service principal.

Et je ne veux pas construire tout le gros système pour le début.

Je pense donc que la question est:

Où stocker les variables d'environnement secrètes et comment accéder à Angular6 code d'application frontale? Il y a plusieurs situations à considérer:

Travailler avec PaaS Heroku config vars
dockerlize (docker-compose, Dockerfile), .env fichier.
Sans service back-end.
ajoutez le fichier de variables d'environnement à .gitignore, ne pas pousser vers SCM (Github, gitlab et ainsi de suite)

smnbbrv · Accepted Answer

TL; DR

Vous ne devez pas traiter environment.ts Comme quelque chose de similaire à process.env. Le nom est similaire mais le comportement ne l'est absolument pas. Si nous parlons du navigateur, les variables d'environnement sont vos éléments sessionStorage/localStorage (localStorage agit plus comme des variables ajoutées à votre profil bash; les cookies et indexedDB se comportent de la même manière). Le environment.ts Est construit à l'intérieur de l'application et n'est donc qu'une partie du code.

C'est pourquoi il n'est pas sûr de mettre des secrets aux environnements.ts en aucune façon. Utilisez des secrets sur le backend sous certaines couches de service ou dans l'un des stockages mentionnés ci-dessus.

version longue

Il n'y a pas de secret dans l'application côté client. Étant donné que votre code dans le navigateur pourra obtenir ces variables, tout le monde pourra obtenir ces variables lors de l'exécution.

Cela signifie que toutes les bibliothèques que vous utilisez explicitement ou implicitement, les extensions de navigateur de l'utilisateur et toute personne capable de flairer votre/votre trafic utilisateur - tout ce qu'ils obtiendront vos secrets assez facilement.

Peu importe comment vous le passez. Grâce à process.env ou environment.ts, tous se retrouveront dans le fichier main.js généré où ils ne sont plus tellement secrets que la discussion suivante est en fait inutile.

Réponse à la partie 1 mise à jour:

Si access_token Est votre jeton (ou votre utilisateur synthétique), vous avez deux options:

Écrivez un service backend qui envoie le code au nom de cet utilisateur Github. Cela signifie que le jeton sera stocké dans la variable d'environnement d'un côté backend, ce qui est une façon très appropriée de faire des choses
Demandez à votre utilisateur d'entrer le jeton pour chaque Push ou demandez-le une fois et stockez-le dans un stockage local. Cela n'a de sens que si chaque utilisateur a son propre/différent jeton

Réponse à la partie 2 mise à jour:

Vous pouvez créer un docker autour de votre frontend, l'exécuter dans un cluster kubernetes à l'intérieur d'une machine virtuelle qui est hébergée sur le serveur le plus sécurisé du monde, il ne sécurisera pas votre token si vous le mettez comme angular variable d'environnement car ce qui est public ne peut pas être secret.

Vous semblez ne pas comprendre le point principal: GitHub vous donne une erreur et ne permet pas de pousser le code, vous devriez déjà être reconnaissant qu'il trouve un problème dans votre architecture. Si vous souhaitez résoudre le problème, utilisez les solutions ci-dessus. Si vous souhaitez simplement contourner la validation de GitHub et que vous ne vous souciez pas de la sécurité, divisez simplement votre chaîne de jetons en deux et stockez-la séparément et GitHub ne pourra pas la trouver.

Réponse à la partie 3 mise à jour:

Vous pouvez exécuter les requêtes Oauth2 de GitHub directement depuis votre frontend. Chacun de vos utilisateurs devrait y avoir un compte et cela résoudrait tous vos problèmes. C'est en fait le même que ce qui a été proposé comme solution # 2.

Si vous optez pour la solution n ° 1 avec un backend, à des fins de développement, pré-configurez simplement le cookie ou utilisez localStorage.setItem('your-token-here'). C'est bien plus que suffisant à des fins de développement.