Utiliser les API de Vonage avec MongoDB Atlas - Partie 4

Dans cette série :

• Partie 1 - Qu'est-ce que MongoDB Atlas ?

• Partie 2 - Utilisation de Vonage Verify avec les ouvertures de session

• Partie 3 - Utilisation de Vonage pour les interactions avec les clients

• Partie 4 - Utilisation d'Atlas pour l'authentification des utilisateurs

• Partie 5 - Utiliser In-App Messaging de Vonage pour les notifications

Nous continuons à nous plonger dans MongoDB Atlas et son utilisation avec diverses API de Vonage. Dans la première partie, nous avons vu ce qu'est MongoDB Atlas et certains des services qu'il offre. Dans la partie 2, nous avons utilisé Vonage Verify pour renforcer la sécurité des utilisateurs lors de l'authentification. La troisième partie a porté sur le contact avec le client pour sa commande et sur ce que nous pouvons faire lorsque les clients ont besoin de parler au restaurant. Dans la quatrième partie, nous mettrons en place le système d'authentification des utilisateurs d'Atlas.

Décharger l'authentification de l'utilisateur

Les applications web ont en commun la nécessité d'authentifier les utilisateurs. Les Applications aident à gérer une partie de cette tâche, mais chaque application construit un code similaire pour faire une chose - confirmer les informations d'identification d'un utilisateur. Nous pouvons utiliser MongoDB Atlas qui possède un système intégré pour authentifier et gérer les utilisateurs.

Ce système est différent de l'authentification que nous faisons à MongoDB et est un service fourni par Atlas. Vous pouvez gérer les utilisateurs via Atlas en tant que service d'authentification tiers (pour votre application). L'utilisation d'Atlas vous permet de prendre en charge de nombreux types d'authentification en toute sécurité.

Pour illustrer cela, le backend administratif de notre démo utilise l'authentification Atlas au lieu de Verify. Ce backend nous permettra de gérer l'inventaire que nous montrons aux utilisateurs et les commandes qui ont été passées. Il nous permettra également de rejoindre les réunions vidéo que les clients ont entamées. En prime, il nous permettra de voir ce qui se passe si nous voulons intégrer l'accès à MongoDB dans notre application au lieu de nous appuyer sur une API dorsale.

Mise en place de l'authentification

Atlas supporte à la fois une interface web et des fichiers de configuration pour de nombreuses fonctionnalités centrées sur l'application. Nous utiliserons l'interface web pour le tutoriel de configuration, mais vous pouvez également utiliser les fichiers d'exemple fournis dans le référentiel de démonstration. Ces fichiers fonctionnent avec l'outil outil CLI de RealmRealm, et nous les avons fournis pour que vous puissiez les comparer à l'interface web. Si vous débutez, je vous recommande d'utiliser l'interface web, mais dans une application gérée, vous voudrez stocker la configuration et utiliser l'outil CLI de Realm pour déployer les changements de configuration. La démo comprend un dossier app-service/ avec des fichiers d'exemple que vous pouvez éditer pour commencer.

Les applications Atlas sont une combinaison de détails de configuration et de code déployé. L'interface Apps permet de travailler facilement avec les paramètres et le code qu'un développeur a déchargé dans les services Atlas.

Pour l'instant, utilisons l'interface web. Une fois connecté à votre projet, cliquez sur "App Services" dans la barre de navigation secondaire supérieure. Une liste des projets d'application configurés s'affiche. S'il s'agit de la première application avec laquelle vous travaillez, une fenêtre s'ouvrira, vous permettant d'accéder aux Applications Services. Sélectionnez "Build your own app" pour l'instant, car nous nous occuperons de tout pour le tutoriel.

New Atlas App dialog

L'écran suivant comporte des questions de configuration. Notre source de données, qui est le cluster que nous utilisons, doit être renseignée. Sélectionnez celui que vous utilisez pour le tutoriel si vous avez plusieurs clusters. Vous pouvez également modifier le nom de l'application. Je nommerai l'application "Frontend" car ce service d'application gérera notre frontend JavaScript pour les pages d'administration. Cliquez sur Créer un service d'application pour continuer, puis sur Fermer les guides pour fermer la fenêtre de démarrage.

Cela nous amène au tableau de bord Applications de notre application Frontend. Comme vous pouvez le voir, vous pouvez faire beaucoup de choses avec une application Atlas, mais pour l'instant, nous nous concentrons sur l'utilisation de l'authentification de l'utilisateur. Dans la section "Data Access" de la barre latérale, cliquez sur Authentification afin de commencer à la configurer.

User authentication options

Comme mentionné précédemment, Atlas supporte plusieurs types d'authentification. Pour l'instant, nous ne nous intéresserons qu'à l'option "Email/Mot de passe". Modifier pour commencer à le configurer.

Sur la page de configuration, activez l'option "Provider Enabled". Dans une application de production, vous voudrez que l'utilisateur vérifie son adresse électronique pour s'assurer qu'elle existe, mais nous pouvons sauter cette étape pour l'instant. Bien que nous ne nous étendions pas sur sa mise en œuvre, vous devez saisir une "URL de réinitialisation du mot de passe". Pour l'instant, saisissez "https://example.com/reset" pour satisfaire le formulaire. Cliquez sur Enregistrer l'ébauche lorsque vous avez terminé.

Email/Password options

Si vous passez le panneau qui s'affiche, toutes les modifications que vous apportez dans Atlas sont considérées comme des modifications de brouillon. Vous pouvez mettre en scène un ensemble de différentes étapes de brouillon et les déployer lorsque tout est prêt. Toutes ces informations sont enregistrées dans des fichiers de configuration qui peuvent être poussés et tirés à l'aide de la CLI de Realm, et les fichiers mentionnés ci-dessus sont stockés dans app-service/ à titre d'exemple.

Une fois que vous avez effectué une modification, vous verrez une bannière en haut de la page qui dit maintenant "Des modifications ont été apportées" avec un bouton pour réviser. Cliquez sur Réviser le brouillon et déployer. Vous verrez un blob JSON qui est une différence de texte entre les anciens et les nouveaux paramètres. Cela vous semblera très familier si vous avez utilisé le système de demande d'extraction de GitHub. Puisque nous venons de faire ce changement, cliquez sur Déployer. Ces paramètres seront poussés vers le service d'application, et nous pourrons commencer à utiliser l'authentification.

Deployment Diff dialog

Nous avons maintenant besoin d'un utilisateur. Cliquez sur Utilisateurs de l'application dans la barre latérale, puis sur le bouton Ajouter un nouvel utilisateur dans la barre latérale, puis sur le bouton Ajouter un nouvel utilisateur. Saisissez une adresse e-mail et un mot de passe valides, puis cliquez sur Créer. La création d'utilisateurs de cette manière n'est pas évolutive. Il existe donc des options permettant de créer des utilisateurs de manière programmatique par le biais d'un processus d'inscription, mais pour l'instant, nous en utiliserons un que nous aurons créé à la main.

À ce stade, l'authentification est configurée pour notre application. Nous pourrions utiliser le SDK MongoDB Realm pour authentifier un utilisateur, mais notre utilisateur actuel n'est rien d'autre qu'une adresse e-mail et un mot de passe. Nous ne pouvons pas stocker d'informations supplémentaires ou indiquer que l'utilisateur est un utilisateur administratif. C'est là qu'interviennent les données utilisateur personnalisées. Nous pouvons lier un utilisateur à une collection de documents qui contiendra des informations supplémentaires sur l'utilisateur, comme son nom, son téléphone ou même s'il est considéré comme un administrateur.

Cliquez sur Paramètres de l'utilisateur. La page de configuration de la liaison des données de l'utilisateur s'affiche.

Custom User Information Settings

Sélectionnez ensuite votre cluster et votre base de données dans les menus déroulants "Nom du cluster" et "Nom de la base de données", respectivement. Pour le "Nom de la collection", sélectionnez "Créer une nouvelle collection", ce qui fera apparaître une nouvelle zone de texte. Dans cette nouvelle zone, entrez user_custom_data et cliquez sur Créer. Nos données personnalisées seront ainsi stockées dans une collection distincte de nos données clients.

Pour le "Champ d'identification de l'utilisateur", entrez user_id. Ce champ servira de clé étrangère à l'utilisateur auquel les données sont rattachées. Bien que nous ayons mentionné ne pas le faire dans la partie 3, c'est l'un des cas où l'utilisation d'une clé étrangère de base de données relationnelle est judicieuse. La table qui stocke les données de l'utilisateur est entièrement gérée, nous n'y avons donc pas d'accès direct, ce qui signifie que nous ne pouvons pas intégrer ces données dans l'enregistrement de l'utilisateur ni stocker les informations d'identification de l'utilisateur avec les données de l'utilisateur.

Une fois que vous avez terminé, cliquez sur Enregistrer le projet puis sur Réviser le brouillon et déployer pour enregistrer les nouveaux paramètres.

Une fois le déploiement effectué, retournez dans la section Utilisateurs (Utilisateurs). Nous voulons marquer notre nouvel utilisateur en tant qu'administrateur, alors créons ces données d'utilisateur personnalisées. Nous aurons besoin de l'ID de l'utilisateur que nous venons de créer, alors copiez cet ID pour l'utilisateur. Retournez ensuite à Services de données dans la barre de navigation supérieure et allez dans Parcourir les collections.

Nous devons créer une nouvelle collection. restaurant_pos_demo le nom de la base de données, et un + apparaîtra à droite du texte. Cliquez dessus, puis entrez user_custom_data comme nom de collection. Cliquez sur Créer pour créer une collection vide. Une fois la collection créée, cliquez sur Insérer un documentpour passer à la vue {} et collez le document JSON suivant.

{
 "user_id": "<user-id-we-just-copied>",
 "admin":true
}

Lorsque nous arrivons au code où nous nous connectons à l'intérieur de notre application, le drapeau admin sera ajouté à l'utilisateur lorsqu'il sera renvoyé. Vous pouvez également ajouter arbitrairement n'importe quelle information à ce document pour toute autre information sur l'utilisateur que vous souhaitez suivre dans votre application. Pour notre tutoriel, nous avons besoin d'un indicateur booléen admin booléen.

Sécurité des requêtes

Nous examinerons une autre section lorsque nous serons dans l'interface utilisateur web de l'Atlas. L'une des fonctionnalités utilisées par notre backend administratif pour le tutoriel est l'interrogation de la base de données directement à partir de notre application côté client. Dans de nombreuses Applications, comme le côté client de notre didacticiel, nous avons une API de backend qui accède à nos données. Atlas nous permet d'interroger la base de données à partir du navigateur en combinant l'authentification de l'utilisateur, que nous venons de mettre en place, et des de contrôles d'accès aux données basés sur des règles.

Cliquez sur Règles à partir de l'écran App Services sous "Data Access", ce qui vous amènera à l'écran Rules, où nous pouvons contrôler l'accès des utilisateurs authentifiés. À l'heure actuelle, notre application ne procède à aucun contrôle des autorisations, mais l'ajouter ne demande que quelques clics.

Atlas App Rules configration

Nous voulons nous assurer que tout utilisateur qui accède à ces données est un administrateur, car les administrateurs sont les seuls à pouvoir accéder à ces données. Pour notre application, nous ne voulons autoriser que les personnes ayant le drapeau admin sur son Account (vous voyez pourquoi nous sommes allés de l'avant et avons mis cela en place plus tôt ?) Vous pouvez imposer des restrictions sur l'ensemble de la base de données ou par schéma. Puisque nous n'autorisons que notre backend d'administration à accéder directement à la base de données, nous pouvons ajouter ces règles à la base de données elle-même. Dans l'écran Règles, cliquez sur Rôles et filtres par défaut juste au-dessus du nom de la base de données.

Nous pouvons définir des rôles prédéfinis, comme refuser tout ou autoriser tout. Nous voulons créer une règle qui utilise nos données personnalisées, alors descendez et cliquez sur Sauter (commencer à partir de zéro).

Admin-Write rule config

Nous devons donner un nom à notre rôle, par exemple "admin-write", puis définir les règles d'application de notre rôle. Puisque nous sommes préoccupés par l'accès aux données lorsque nous sommes un administrateur, nous pouvons établir une règle simple qui garantit que l'utilisateur a un attribut de données personnalisé appelé admin et qu'il est défini sur true. Copiez et collez le bloc de JSON ci-dessous dans l'éditeur.

{
    "%%user.custom_data.admin": true
}

%%user indique au système de règles de vérifier l'utilisateur authentifié. Lors de l'authentification, les informations stockées dans user_custom_data sont attachées à l'utilisateur renvoyé et attribuées à la propriété custom_data propriété. Vous pouvez ajouter autant de règles que vous le souhaitez pour rendre le système aussi granulaire que vous le souhaitez dans une application réelle.

En dessous, nous pouvons définir les autorisations sur les documents. Puisque nous sommes un utilisateur administrateur, nous sélectionnons "Insérer", "Supprimer" et "Rechercher", ce qui donnera à tout utilisateur administrateur un accès complet à tous les documents de n'importe quelle collection. Enfin, nous avons les autorisations relatives aux champs. Vous pouvez définir des règles d'accès jusqu'au fichier spécifique d'une collection. Pour l'instant, sélectionnez "Lire et écrire tous les champs".

Ces deux paramètres sont plus utiles lorsque vous souhaitez, par exemple, réserver les vues en lecture seule à des rôles d'utilisateurs spécifiques ou restreindre les champs aux rôles qui n'ont qu'un certain accès à l'information. Ces règles peuvent être utilisées conjointement avec des règles de filtrage plus larges qui limitent les données pouvant être renvoyées par une requête.

Enregistrez tous ces paramètres, puis examinez et déployez nos nouveaux contrôles d'accès.

La dernière chose à faire est d'indiquer à notre application avec quelle application Atlas elle doit communiquer. Sur la page d'accueil de l'application Atlas que nous utilisons, près du haut se trouve un App ID. Copiez-le et entrez-le dans le fichier .env de l'application web sous VITE_REALM_ID.

App ID location

Peut-on déjà se connecter ?

Oui !

Rendez-vous sur http://localhost:5173/login et connectez-vous en utilisant l'adresse électronique et le mot de passe que vous avez attribués à l'utilisateur dans Atlas. Vous devriez être accueilli par un écran d'inventaire et l'option d'ajouter de nouveaux plats. Si vous voyez cela, vous êtes authentifié !

Tutorial Admin Area

MongoDB Atlas dispose d'un SDK pour navigateur qui peut être utilisé pour contacter notre cluster et notre application Atlas. Nous devons prendre une adresse email et un mot de passe pour notre application et les passer dans les appels d'authentification du SDK.

import { MongoDBRealmError } from 'realm-web';
import { ref } from 'vue'
import { useRouter } from 'vue-router';
import { authenticationStore } from '../stores/authenticationStore';

const router = useRouter();
const username = ref('')
const password = ref('')
const authStore = authenticationStore()

const login = async () => {
    try {
        await authStore.login(username.value, password.value)
        router.push({ name: 'inventory.home' });
    } catch (error) {
        if (error instanceof MongoDBRealmError) {
            console.log(error.errorCode)
        }
    }
}

Le code VueJS est relativement minimal. Notre composant composant Login.vueNous avons un magasin d'authentification qui, comme notre panier d'achat, est une enveloppe qui facilite la transmission des informations relatives à l'utilisateur connecté. Ce magasin utilisera le SDK pour se connecter. Sur cette page, nous n'avons qu'à attendre que l'utilisateur se connecte à l'aide du formulaire et à appeler authStore.login() avec le nom d'utilisateur et le mot de passe.

import { defineStore } from 'pinia'
import * as Realm from 'realm-web'

const realmApp = new Realm.App({id: import.meta.env.VITE_REALM_ID})

export const authenticationStore = defineStore('authenticationStore', {
    state: () => {
        return {
            token: null,
            user: null,
        }
    },
    actions: {
        async login(username, password) {
            const creds = Realm.Credentials.emailPassword(username, password);
            this.user = await realmApp.logIn(creds)
            return this.user
        },
        setToken(token: string) {
            this.token = token
        },
        logout() {
            this.token = null
        }
    }
})

Le magasin d'authentification magasin d'authentification n'est rien d'autre qu'une enveloppe pour le SDK MongoDB et quelques endroits où conserver les informations sur les utilisateurs. Nous créons un magasin en utilisant Pinia et créons un nouvel objet Realm.App() avec un lien vers l'App ID que nous avons ajouté à notre fichier .env que nous avons ajouté à notre fichier À l'intérieur de notre objet authenticationStore se trouve une méthode login() appelée Realm.Credentials.emailPassword(). Celle-ci génère un ensemble d'informations d'identification de l'utilisateur que nous pouvons transmettre à l'objet app pour l'authentifier. Si l'appel à realmApp.login() est réussi, nous obtenons un utilisateur en retour. Nous stockons cet utilisateur et pouvons l'extraire du magasin à tout moment.

À partir de ce moment, notre utilisateur est considéré comme authentifié. À tout moment, nous pouvons vérifier authenticationStore.user et s'il existe, nous sommes authentifiés. Puisque nous nous sommes connectés à Atlas via le SDK, nous pouvons également accéder à la base de données directement à partir de l'interface. Nous le faisons par l'intermédiaire d'un Magasin de base de données. Tout ce que fait ce magasin est de maintenir une connexion à notre cluster MongoDB et d'utiliser les informations d'identification de l'utilisateur connecté.

Ceci est puissant car nous pouvons effectuer des recherches de données directement dans le navigateur au lieu de dépendre de notre API dorsale. Nous pouvons verrouiller cet accès aux seuls utilisateurs administrateurs en utilisant les règles que nous avons définies dans la configuration de l'application Atlas. Si nous voulions nous débarrasser de tout le code MongoDB dans notre API dorsale, nous pourrions ajouter des règles et des filtres supplémentaires pour verrouiller les utilisateurs afin qu'ils ne voient que les données auxquelles ils peuvent accéder. C'est un excellent moyen d'esquisser rapidement une application.

import { defineStore } from 'pinia'
import { authenticationStore } from './authenticationStore'

const authStore = authenticationStore()
const dataSource = import.meta.env.VITE_MONGODB_DATA_SOURCE
const databaseName = import.meta.env.VITE_MONGODB_DATABASE

export const mongodbStore = defineStore('mongodbStore', {
    state: () => {
        return {
            restaurantDb: authStore.user.mongoClient(dataSource).db(databaseName),
        }
    },
    actions: {
        getInventoryCollection() {
            return this.restaurantDb.collection('inventory')
        }
    }
})

Le magasin de base de données est très minimal. Nous facilitons l'extraction de l'objet de base de données et de la collection à partir de la connexion Realm que nous avons établie dans le magasin d'authentification. Nous pouvons ensuite interroger la base de données à partir de notre code VueJS, comme dans le composant composant Inventaire:

import { ref } from 'vue';
import { mongodbStore } from '../stores/mongodbStore';

const dbStore = mongodbStore()
let inventory = ref(Array());

async function getInventory() {
    const dishes = await dbStore.getInventoryCollection().find()
    inventory.value = Array()
    dishes.forEach(dish => {
        if (dish.name) {
            inventory.value.push(dish)
        }
    })
}

Dans notre composant VueJS, nous intégrons la base de données en tant que mongodbStore. Nous pouvons ensuite utiliser la syntaxe du SDK MongoDB pour trouver les documents à utiliser. Puisque nous voulons tous les documents de la collection d'inventaire, nous pouvons utiliser dbStore.getInventoryCollection().find() pour obtenir tous les documents auxquels nous avons accès. Nous pouvons ensuite les pousser dans un objet VueJS ref() pour les afficher sur la page.

La page Règles de l'application Atlas peut être utilisée pour restreindre les documents que nous pouvons voir. Par exemple, il est courant de lier un document à un utilisateur, tel qu'un auteur (ou, dans notre cas, la personne qui a passé une commande). Vous pouvez mettre en place un filtre qui ne renverra que les commandes de cet utilisateur, même s'il a fait un appel à find() pour tout renvoyer. Les restrictions et les filtres définis dans la section Règles de l'application Atlas complètent toute requête effectuée par le navigateur.

Conclusion

Atlas Applications peut aider à réduire drastiquement une partie du temps de développement des applications grâce à des choses comme l'authentification des utilisateurs et l'accès aux requêtes. Nous pouvons complètement ignorer beaucoup de fonctionnalités, comme la possibilité de publier des fonctions sur une plateforme sans serveur ou d'activer une passerelle API pour créer une architecture de micro-services pour votre navigateur ou votre application mobile. Il existe même des systèmes de réplication de données pour fournir des capacités hors ligne et de synchronisation des données aux Applications.

Maintenant que nous sommes connectés, il nous reste un élément à examiner. Lorsqu'un utilisateur a un problème, comment pouvons-nous le savoir ? Nous examinerons l'écran d'administration des commandes et la façon dont nous pouvons tirer parti de la messagerie In-App Messaging de Vonage pour obtenir des notifications dans le navigateur lorsqu'un utilisateur a soumis une demande de réunion et comment nous utilisons l'API Meetings pour donner au restaurant des capacités d'hébergement vidéo qui ne sont pas disponibles pour le client.

• Partie 1 - Qu'est-ce que MongoDB Atlas ?

• Partie 2 - Utilisation de Vonage Verify avec les ouvertures de session

• Partie 3 - Utilisation de Vonage pour les interactions avec les clients

• Partie 4 - Utilisation d'Atlas pour l'authentification des utilisateurs

• Partie 5 - Utiliser In-App Messaging de Vonage pour les notifications