Passer au contenu principal
Auth0 stocke les informations des utilisateurs de votre locataire dans une base de données hébergée dans le nuage, ou vous pouvez choisir de stocker les données des utilisateurs dans votre propre base de données externe personnalisée. Pour stocker des données utilisateur au-delà des informations de base qu’Auth0 utilise pour l’authentification, vous pouvez utiliser le magasin de données Auth0 ou une base de données personnalisée. Cependant, si vous utilisez les données supplémentaires à des fins d’authentification, nous vous recommandons d’utiliser le magasin de données Auth0, car il vous permet de gérer vos données utilisateur via le Auth0 Management Dashboard.

​
Base de données externe par rapport au magasin de données Auth0

Le magasin de données Auth0 est personnalisé pour les données d’authentification. Le stockage d’informations autres que celles de l’utilisateur par défaut ne doit être effectué que dans des cas limités. Voici pourquoi :
  • Évolutivité : Le magasin de données Auth0 est limité en termes d’évolutivité, et les données de votre application peuvent dépasser les limites appropriées. En utilisant une base de données externe, vous gardez votre magasin de données Auth0 simplifié, tandis que la base de données externe, plus efficace, contient les données supplémentaires;
  • Performance : Vos données d’authentification sont probablement consultées moins souvent que vos autres données. Le magasin de données Auth0 n’est pas optimisé pour une utilisation à haute fréquence, c’est pourquoi vous devriez stocker ailleurs les données qui doivent être récupérées plus souvent;
  • Flexibilité : Le magasin de données Auth0 ayant été conçu pour accueillir uniquement des profils utilisateurs et leurs métadonnées, les actions que vous pouvez effectuer sur la base de données sont limitées. En utilisant des bases de données séparées pour vos autres données, vous pouvez gérer vos données de manière appropriée.
Lorsque vous externalisez l’authentification des utilisateurs, il n’est généralement pas nécessaire de maintenir votre propre table utilisateurs/mots de passe. Néanmoins, il se peut que vous souhaitiez associer des données d’application à des utilisateurs authentifiés.
  • Par exemple, vous pourriez avoir une table Utilisateurs qui répertorie chaque utilisateur authentifié par Auth0. Chaque fois qu’un utilisateur se connecte, vous pouvez rechercher cet utilisateur dans la table. Si l’utilisateur n’existe pas, vous créez un nouvel enregistrement. S’il existe, vous mettez à jour tous les champs, conservant ainsi une copie locale de toutes les données de l’utilisateur.
  • Vous pouvez également stocker l’identifiant de l’utilisateur dans chaque table/collection contenant des données associées à l’utilisateur. Il s’agit d’une implémentation plus simple, adaptée aux petites applications.

​
Exemple de scénario de stockage de données utilisateur

Auth0 fournit un exemple d’application, une application de musique mobile, qui reflète l’expérience utilisateur de bout en bout lors de l’utilisation d’Auth0 avec une base de données externe personnalisée. Cet exemple d’application est une application iOS créée à l’aide du projet seed Auth0 iOS. Le système dorsal utilise l’API Node.js. Pour une visualisation de la structure globale de l’application, voir le scénario d’architecture Mobile + API.

​
Métadonnées

​
Métadonnées d’application

Les points de données suivants de notre application de musique mobile sont appropriés pour être stockés dans app_metadata :
  • Plan d’abonnement de l’utilisateur
  • Droit (ou absence de droit) de l’utilisateur à modifier les listes de lecture en vedette
Ces deux points de données doivent être stockés dans app_metadata plutôt que dans user_metadata, car ils ne doivent pas être directement modifiables par l’utilisateur.

​
Métadonnées de l’utilisateur

Les points de données suivants, issus de notre application de musique mobile, peuvent être stockés dans user_metadata :
  • Préférences de l’application
  • Détails choisis par l’utilisateur pour modifier son expérience de l’application lors de la connexion.
Notez que, contrairement aux points de données pour app_metadata, l’utilisateur peut facilement et aisément modifier ceux stockés dans user_metadata. Nous pouvons permettre à l’utilisateur de modifier son displayName, qui est le nom que l’utilisateur voit lorsqu’il se connecte et qui est affiché aux autres utilisateurs de l’application. Pour afficher l’identifiant choisi par l’utilisateur à chaque fois qu’il se connecte, nous utilisons une règle pour obtenir la valeur user.user_metadata. 
function(user, context, callback){
  user.user_metadata = user.user_metadata || {};
  user.user_metadata.displayName = user.user_metadata.displayName || "user";

  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
    .then(function(){
      callback(null, user, context);
    })
    .catch(function(err){
      callback(err);
    });
}
Voici un aperçu de l’écran que l’utilisateur utiliserait pour modifier son displayName :
Écran des paramètres de l'application iOS avec option de mise à jour du nom d'affichage.
pour enregistrer les modifications dans la base de données, l’application appelle le point de terminaison Obtenir un utilisateur de pour identifier l’utilisateur approprié : cet appel est suivi d’un appel au point de terminaison Mettre à jour un utilisateur pour mettre à jour le champ user_metadata : vous devez remplacer {yourAccessToken} par un jeton d’accès à Management API.

​
Règles d’autorisation des données utilisateur

Utilisez des rules pour mettre en place des autorisations permettant à un utilisateur de modifier ou non les listes de lecture en vedette.

​
Attribuer le rôle d’éditeur de liste de lecture

La première règle envoie une demande à notre API Node, qui interroge ensuite la base de données connectée à Heroku pour vérifier le nombre de lectures de la liste de lecture de l’utilisateur. Si le nombre est égal ou supérieur à 100, nous attribuons la valeur playlist_editor au tableau roles dans app_metadata. 
function (user, context, callback) {

  var request = require('request');

  user.app_metadata = user.app_metadata || {};
  user.app_metadata.roles = user.roles || [];

  var CLIENT_SECRET = configuration.AUTH0_CLIENT_SECRET;
  var CLIENT_ID = configuration.AUTH0_CLIENT_ID;

  var scope = {
    user_id: user.user_id,
    email: user.email,
    name: user.name
  };

  var options = {
    subject: user.user_id,
    expiresInMinutes: 600,
    audience: CLIENT_ID,
    issuer: 'https://example.auth0.com'
  };

  var id_token = jwt.sign(scope, CLIENT_SECRET, options);

  var auth = 'Bearer ' + id_token;

  request.get({
    url: 'https://example.com/playlists/getPlays',
    headers: {
       'Authorization': auth,
      'Content-Type': 'text/html'
    },
    timeout: 15000
  }, function(err, response, body){
    if (err)
      return callback(new Error(err));
    var plays = parseInt(body, 10);

    if (plays >= 100 && user.roles.indexOf('playlist_editor') < 0){
      user.app_metadata.roles.push('playlist_editor');
      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
        .then(function(){
          callback(null, user, context);
        })
        .catch(callback);
    }

    else if (plays < 100 && user.roles.indexOf('playlist_editor') >= 0){
      user.app_metadata.roles = [];
      auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
        .then(function(){
          callback(null, user, context);
        })
        .catch(callback);
    }
    else{
      callback(null, user, context);
    }

  });

}

​
Le paramètre scope spécifie le rôle

La deuxième règle récupère le champ app_metadata et affecte le tableau des roles à un champ de l’objet utilisateur afin qu’il soit accessible sans appeler app_metadata sur l’application. Le paramètre scope peut alors spécifier les roles lors de la connexion de l’utilisateur sans inclure tout ce qui se trouve dans app_metadata dans l’objet utilisateur : 
function(user, context, callback) {
   if (user.app_metadata) {
      user.roles = user.app_metadata.roles;
   }
   user.roles = user.roles || [];
   callback(null, user, context);
}
Après avoir implémenté ces deux règles, l’application reconnaît si l’utilisateur est un éditeur de liste de lecture ou non et modifie l’écran d’accueil en conséquence. Si playlist_editor figure dans le tableau des roles stocké dans les app_metadata de l’utilisateur, ce dernier sera accueilli en tant que ÉDITEUR après s’être connecté :
Example of user profile page with editor role.

​
Associer la musique d’un utilisateur à l’utilisateur

Nous devons associer la musique d’un utilisateur à cet utilisateur, mais cette information n’est pas nécessaire pour l’authentification. Voici comment stocker ces informations dans une base de données distincte, intégrée au système dorsal de l’application. L’identifiant unique de l’utilisateur est le user_id. Voici un exemple de ligne de la table songs de notre base de données :
song_idsongnameuser_id
1Succès numéro ungoogle-oauth2
Le système dorsal Node.js authentifie les demandes adressées à l’URI associé à l’obtention des données personnelles de l’utilisateur à partir de la base de données en validant un jeton Web JSON. En savoir plus sur l’authentification basée sur un jeton et comment mettre en œuvre le JWT dans vos applications. Voici le code mettant en œuvre la validation à partir du projet Node.js seed : 
var genres = require('./routes/genres');
var songs = require('./routes/songs');
var playlists = require('./routes/playlists');
var displayName = require('./routes/displayName');

var authenticate = jwt({
  secret: process.env.AUTH0_CLIENT_SECRET,
  audience: process.env.AUTH0_CLIENT_ID
});

app.use('/genres', authenticate, genres);
app.use('/songs', authenticate, songs);
app.use('/playlists', authenticate, playlists);
app.use('/displayName', authenticate, displayName);
Nous pouvons ajouter des fonctionnalités pour gérer différentes demandes de données à partir de notre application. Par exemple, si nous recevons une demande GET à /secured/getFavGenre, l’API appelle la fonction queryGenre(), qui interroge la base de données et répond avec le genre préféré de l’utilisateur. 
@IBAction func getGenre(sender: AnyObject) {
        let request = buildAPIRequest("/genres/getFav", type:"GET")
        let task = NSURLSession.sharedSession().dataTaskWithRequest(request) {[unowned self](data, response, error) in
            let genre = NSString(data: data!, encoding: NSUTF8StringEncoding)
            dispatch_async(dispatch_get_main_queue(), {
                self.favGenre.text = "Favorite Genre:  \(genre!)"
            })
        }
        task.resume()
    }
La fonction buildAPIRequest() prend le chemin et la méthode HTTP de la demande comme paramètres et crée une demande en utilisant la base URL de notre API Node.js qui est hébergée sur Heroku. Dans l’application, la fonction getGenre() fait une demande à l’API et modifie l’interface de l’application pour afficher la réponse à la demande /genres/getFav. Le système dorsal récupère les données nécessaires à cette action en utilisant la fonction queryGenre() et renvoie les résultats à l’application. 
function queryGenre(user_id, res){

  db.connect(process.env.DATABASE_URL, function(err, client) {
  if (err) throw err;

  client
    .query('SELECT fav_genre as value FROM user_data WHERE user_id = $1', [user_id], function(err, result) {

      if(err) {
        return console.error('error running query', err);
      }
      res.send(result.rows[0].value);
    });
  });

};

​
En savoir plus