Le projet est un spa Vue et quelques composants doivent faire des demandes d'accès à une API avec une clé secrète. Je souhaite actuellement télécharger le projet sur GitHub Pages, cependant, je ne veux pas télécharger la clé.
J'ai lu que j'ai besoin de créer un fichier qui doit contenir une variable avec ma clé, puis utilisez cette variable à la place de la clé secrète, cependant, je ne sais pas comment y aller. < / p>
3 Réponses :
Si vous utilisez le côté client clé, vous l'exposez à chaque utilisateur de l'application.
La mise dans une variable signifie simplement que cela n'apparaît que dans un endroit dans le code source. Il est toujours visible là-bas et dans chaque demande envoyée à l'API (où il se peut facilement être trouvé avec l'onglet Réseau dans les outils de développement du navigateur).
Pour le garder secret, vous devez écrire côté serveur pour accéder à l'API, puis exposez les données à votre application VUE via un autre mécanisme (généralement un service Web de votre choix).
Suis-je comprendre correctement que si je n'ai qu'un spa front-end qui consomme une API d'un tiers et que je souhaite héberger ce spa, je ne peux pas le faire à moins d'exposer la clé de l'API pour l'API tiers?
Corriger. Généralement, vous constaterez que la permission de Cors n'est pas fournie pour les API nécessitant des clés secrètes.
J'utilise l'API Google Maps API et Google Places API et j'ai mon propre back-end. Chaque fois que je veux obtenir tous les sites touristiques dans une certaine ville, je dois faire une demande d'obtention de mon dos afin qu'il puisse faire une demande d'obtention de Google Places API parce que je n'ai pas la permission de Cors si cela fait du front finir. Cependant, certaines des fonctionnalités ne nécessitent pas que je fasse la demande d'obtention de mon dos et que c'est le cas, je viens de faire la demande du front-end. Par exemple Cartes .googleapis.com / Maps / API / GEOCODE / ...
Vous pouvez utiliser un fichier d'environnement qui ne fait pas partie du code source et le charger dans votre code d'extrémité avant via dotenv paquet ou similaire
Je suis d'accord. Les fichiers env sont souvent utilisés dans ce cas car ajoutent une sécurité avec la fonctionnalité et éviter la complexité
Le fichier .env aura toujours besoin d'être téléchargé sur Github et l'OP souhaite utiliser des pages GitHub pour héberger son projet. Le fichier .env sera visible pour tous ceux qui vérifient le référentiel correct? C'est ce que la question était de la question.
Vous téléchargez un .env.diste qui (regarde ma réponse) est un modèle rempli au moment du déploiement avec les bonnes valeurs.
Il restera toujours visible à l'avant, quelle que soit tout ce qui est fait pour le garder hors de la répétition du Git public.
Cela dépend de l'API et du type d'application, où nous avons une API qui peut fournir une signature comme AWS Ceci est viable, lorsqu'un serveur doit gérer la demande d'authentification et la réponse de l'API pour chaque client, cela pourrait devenir un goulot d'étranglement inutile. La sensibilité des données échangée avec l'API est également un paramètre. Récupération de photos Instagram n'est pas la même qui récupère les factures client.
Si vous ne pouvez pas compter sur un serveur pour le stocker comme suggéré ci-dessus, vous pouvez le stocker dans un modèle de variable env.
auth.env.diste Il y a Ceci permet également de scinder le comportement de votre authentification dans (c.-à-d.) Essai, environnement de mise en scène et de production. Cet article est très complet et prend en compte beaucoup de scénarios avec des avantages et des inconvénients, expose également l'architecture d'une gestion des capteurs de clés.
Le fichier .env aura toujours besoin d'être téléchargé sur Github et l'OP souhaite utiliser des pages GitHub pour héberger son projet. Le fichier .env sera visible pour tous ceux qui vérifient le référentiel correct? C'était ce que la question de toute la question était à propos.
Les paramètres .Env.Dist sont vides sur le repo et peuplé au moment du déploiement.
OK, supposons qu'il est renseigné au moment du déploiement (comment vous le faites sur GitHub Pages, je n'ai aucune idée) ... Le fichier env est ensuite livré au client pour nous pour nous ... Il est donc visible pour l'utilisateur du navigateur ... Donc, ce n'est plus secret.
Vous avez raison @quentin mais la sécurité et la complexité doivent être équilibrées à la portée, à l'IMHO. Serverside Solution est mieux à coup sûr, mais vous devez parfois équilibrer la sécurité avec la complexité
Si vous équilibrez ceux-ci, cette approche ajoute une complexité importante pour une sécurité absolument nulle.
Je répète, je suis d'accord avec vous, mais "zéro sécurité" pour les utilisateurs poussés et les API non sensibles conviennent parfois. IE: Google Directions API: Oui, vous pouvez proxy l'ensemble des directions Google Serveride, mais est égale à tirer avec un bazooka à un moustique.