Bonjour,

Dans le cadre de la mise en place d'un front-end en Javascript (Vue2 ou Angular par exemple), lorsqu'on doit gérer des fichiers de configurations comment le faire ? 

Aujourd'hui mon front en PHP (zend2. Un back qui appelle un autre back pour générer des vues quoi..) et je passe en variable d'environnement les paramètres de connexions aux APIs et d'autres paramètres de configuration. J'ai arrêté les fichiers de configuration (avec credentials) directement dans le code donc je veux pas me retrouver à faire ça en JS.. 

Donc pour du JS, vu qu'il n'y a pas de serveur, quelle est la bonne pratique à mettre en place pour gérer ça ? J'ai vu qu'il existait du Serveur-Side Rendering mais je ne sais pas si c'est vraiment ça qui répond au sujet. 

Des avis éclairés ? 

Meci!

La bonne pratique pour le front, c'est de ne pas mettre de credentials qui permettent d’accéder à toutes les ressources sur le back. Mais tu vas devoir quand même mettre des credentials...

L'idée et de bien définir les points d'entrée de ton back:

- ceux publiques (qui ne nécéssite pas d'autorisation spécifiques; par exemple le login, la listes des news, une faq, etc...)

- ceux privés (qui nécessite une authentification d'une utilisateur).

Les credentials du coté front peuvent être "volé" très facilement (inspecter le code sur un navigateur; une simple décompilation pour une app dans une webview...). Il est donc important de limiter les choses que l'on peut faire avec: utiliser les point d'entrées publiques. Celà ne signifie pas que l'on ne doit pas sécurisé l'accès public avec un ID et un secret ! Juste qu'il faut toujours avoir en tête que ces informations sont publiques. On utilise couramment le header HTTP : AUTHORIZATION en mode Basic. Le clientId et le secret sont concaténé, avec un séparateur comme ":", le tout encodé en base 64. Par exemple, "clientId:secret" doit donner "Basic Y2xpZW50SWQ6c2VjcmV0".

Pour utiliser les points d'entrée privés, il va falloir obtenir d'autre credentials (un jeton permettant d'identifier l'utilisateur; JWT fait très bien l'affaire), obtenus après authentification. (On utilisera ce jeton avec le header HTTP : AUTHORIZATION en mode Bearer ) En général, ce token est sauvegardé dans le localStorage, ou sessionStorage.

Et pour répondre à ta question "où sauvegarder la configuration", j'utilise personnelement un simple fichier config.json

export const config: any = {
  "url": "http://api.mon-site.com",
  "clientId: "ABCDEF",
  "secret": "123456"
};

Que j'utilise avec Angular 2

import { config } from "config.json";

@NgModule({
 ...
 imports: [
    MonAPIModule.forRoot(config),
    ...
 ]
 ...
})

Ensuite, le build fusionnera toutes mes sources pour me fournir un seul fichier app.js, minifié et optimisé.

-
Edité par Sebajuste 22 mai 2018 à 14:40:45

Merci Sebajuste pour ta réponse,

Effectivement, pour l'authentification à mon API je vois bien le truc et c'est ce que je fais déjà en PHP (avec oauth2) et sans récupération du mot de passe d'un utilisateur on a accès seulement aux services ne nécessitant pas d’autorisation.

Il y a des cas clairs où je peux laisser le back  appeler une API tierces mais aussi d'autres où c'est le front qui doit sans charger. Les API google maps par exemple ou d'autres pour lesquelles je n'ai qu'une API Key que je ne souhaite pas rendre visible. Je devrais passer par le back afin de récupérer la clef puis faire l'appel HTTP dont j'ai besoin ?

En un mot : Oui.

Si tu met ta clef API google map dans ton code front, n'importe qui peu la lire.

Si tu retourne la clef API google map vers le front par ton back, sur un endpoint sécurisé, n'importe qui peu aussi la lire. Car il suffira à n'importe qui de créer un compte, et d'inspecter les retours réseau pour voir la clef (sous chrome F12 -> onglet Network).

En fait, il faut regarder à qui appartient la clef de l'API tierce:

- Si la clef appartient à l'ensemble de l'application, alors elle doit rester privé, et donc du coté back. Tu dois alors fournir tes propres endpoints pour faire une sorte de "proxy" vers l'API tierce, appelé communément "API Gateway".

- Si la clef appartient à l'utilisateur (une clef par utilisateur; par exemple une clef pour récupérer des informations du compte facebook via leur API) alors tu peux la renvoyer sur le front. Car l'utilisateur ne pourra que "voler" sa propre clef.

Ces problématiques de l'utilisation d'API tierce son commune à beaucoup d'application, et certaines solution générique existe. Mais comme toute solution générique, elle ne sont pas toujours adapté aux besoin de chacun... Ca vaut toutefois le coût de chercher de ce coté. Mots clefs sur un moteur de recherche "API management"

Okay ! 

Je vais étudier ça tranquillement, merci pour tes réponses.