NgSysV.A Serious Svelte InfoSys : une version client-serveur-js tutoriel-php.cn

NgSysV.A Serious Svelte InfoSys : une version client-serveur

Linda Hamilton

Libérer： 2024-12-01 09:56:17

original

695 Les gens l'ont consulté

Cette série d'articles est indexée sur NgateSystems.com. Vous y trouverez également une fonction de recherche par mot-clé très utile.

Dernière révision : 24 novembre

1. Présentation

La publication 3.3 a apporté de mauvaises nouvelles : l'objet d'authentification Firestore utilisé côté client pour fournir des informations sur un utilisateur connecté n'est pas disponible côté serveur. Cela a les conséquences suivantes :

Le code de la base de données côté serveur doit utiliser l'API Firestore Admin. En effet, le code API Firestore Client qui soumet les appels aux "règles" de la base de données selon lesquelles l'authentification de référence échoue lorsque l'authentification n'est pas disponible. En revanche, les appels de l'API Admin ne se soucient pas des règles de base de données. Si vous supprimiez les règles, les appels d'API client fonctionneraient côté serveur, mais cela laisserait votre base de données ouverte aux cyberattaques (vous travaillez sur votre base de données Firestore en direct depuis que vous avez commencé à utiliser votre terminal VSCode local - pensez-y) .
Le code côté serveur qui utilise des éléments de données tels que userName et userEmail dérivés de auth doit trouver un autre moyen d'obtenir ces informations.

Cet article décrit comment surmonter ces problèmes pour produire une application Web hautes performances qui s'exécute de manière sécurisée et efficace côté serveur.

2. Code côté serveur Svelte authentifié en pratique

Si vous êtes déjà habitué aux signatures d'appel des clients, l'obligation de passer à l'API d'administration Firestore est une nuisance. Mais vous vous y habituerez vite, donc cela ne devrait pas vous retarder considérablement.

Obtenir des données utilisateur, cependant, est une autre affaire. Pour de nombreuses applications, l'accès aux propriétés utilisateur telles que uId est essentiel à leur conception. Par exemple, une application Web peut devoir garantir que les utilisateurs ne peuvent voir que leurs propres données. Malheureusement, organiser cela est tout un combat. C'est parti :

Tout d'abord, sur le client, vous devez trouver un moyen de créer un package "idToken" contenant tout ce que votre code côté serveur pourrait avoir besoin de savoir sur un utilisateur. Google fournit un mécanisme getIdToken() pour construire cela à partir des données de session d'authentification de l'utilisateur.
Ensuite, vous devez trouver un moyen de transmettre ce package au serveur. Le mécanisme utilisé ici l'enregistre dans un "en-tête" qui est ajouté aux appels des clients au serveur.
Ensuite, vous devez obtenir un « compte de service » Google qui vous permet d'authentifier votre utilisation de l'API Firestore Admin sur un serveur Google. Les clés qui définissent cela doivent être intégrées de manière sécurisée dans vos fichiers de projet (rappelez-vous la discussion sur firebaseConfig.env dans l'article 3.3.
Et enfin, votre code côté serveur doit présenter ces clés de compte de service partout où vous devez utiliser une base de données Firestore.