Stockage des données utilisateur

Découvrez les différences entre l’utilisation du stockage de données Auth0 et d’une base de données externe pour stocker les données utilisateur.

Auth0 stocke les informations des utilisateurs de votre tenant dans une base de données infonuagique hébergée, ou vous pouvez choisir de stocker les données utilisateur dans votre propre base de données externe personnalisée.

Pour stocker des données utilisateur au-delà des renseignements de base qu’Auth0 utilise pour l’authentification, vous pouvez utiliser le stockage de données Auth0 ou une base de données personnalisée. Toutefois, si vous utilisez ces données supplémentaires à des fins d’authentification, nous vous recommandons d’utiliser le stockage de données Auth0, car cela vous permet de gérer vos données utilisateur dans le tableau de bord de gestion Auth0.

​

Base de données externe vs. stockage de données Auth0

Le stockage de données Auth0 est conçu pour les données d’authentification. Le stockage de tout ce qui dépasse les renseignements utilisateur par défaut ne devrait se faire que dans des cas limités. Voici pourquoi :

• Évolutivité : le stockage de données Auth0 présente des limites en matière d’évolutivité, et les données de votre application pourraient dépasser les seuils appropriés. En utilisant une base de données externe, vous gardez votre stockage de données Auth0 simple, 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 stockage de données Auth0 n’est pas optimisé pour une utilisation à haute fréquence; vous devriez donc stocker ailleurs les données qui doivent être récupérées plus souvent;
• Souplesse : comme le stockage de données Auth0 a été conçu pour prendre en charge uniquement les profils utilisateur et les métadonnées qui y sont associées, vous êtes limité quant aux opérations que vous pouvez effectuer sur la base de données. En utilisant des bases de données distinctes pour vos autres données, vous pouvez les gérer comme il se doit et effectuer des requêtes directes sans utiliser l’Management API d’Auth0.

Lorsqu’on confie l’authentification des utilisateurs à un service externe, il n’est généralement pas nécessaire de maintenir sa propre table utilisateurs/mots de passe. Cela dit, vous pouvez quand même vouloir associer les données de l’application aux utilisateurs authentifiés.

• Par exemple, vous pourriez avoir une table Users qui répertorie chaque utilisateur authentifié par Auth0. Chaque fois qu’un utilisateur se connecte, vous pourriez le rechercher dans la table. Si l’utilisateur n’existe pas, vous créeriez un nouvel enregistrement. S’il existe, vous mettriez à jour tous les champs, ce qui reviendrait essentiellement à conserver une copie locale de toutes les données utilisateur.
• Vous pourriez aussi stocker l’identifiant de l’utilisateur dans chaque table/collection contenant des données qui lui sont associées. Il s’agit d’une mise en œuvre plus simple, adaptée aux applications de plus petite taille.

​

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

Auth0 fournit un exemple d’application — une application mobile de musique — qui illustre l’expérience utilisateur de bout en bout lorsqu’on utilise Auth0 avec une base de données externe personnalisée. Cette application d’exemple est une application iOS créée à l’aide du projet de démarrage Auth0 iOS. Le backend utilise l’API Node.js.

Pour voir une visualisation de la structure globale de l’application, consultez le scénario d’architecture Mobile + API.

​

Métadonnées

​

Métadonnées d’application

Les éléments de données suivants de notre application mobile de musique peuvent être stockés dans app_metadata :

• Le forfait d’abonnement de l’utilisateur
• Le droit de l’utilisateur de modifier ou non les listes de lecture en vedette

Ces deux éléments de données devraient être stockés dans app_metadata plutôt que dans user_metadata, puisqu’ils ne devraient pas pouvoir être modifiés directement par l’utilisateur.

​

Métadonnées utilisateur

Les données suivantes de notre application musicale mobile se prêtent bien au stockage dans user_metadata :

• Préférences de l’application
• Choix faits par l’utilisateur pour personnaliser son expérience de l’application à la connexion.

Notez que, contrairement aux données de app_metadata, l’utilisateur peut facilement modifier celles qui sont stockées dans user_metadata.

Nous pouvons permettre à l’utilisateur de modifier son displayName, c’est-à-dire le nom qu’il voit lorsqu’il se connecte et qui s’affiche 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 à quoi ressemble l’écran que l’utilisateur utiliserait pour modifier son displayName :

Pour enregistrer les modifications dans la base de données, l’application envoie une requête vers le point de terminaison Get a User de la Management API afin d’identifier l’utilisateur visé :

Cette étape est suivie d’une requête au point de terminaison Update a User pour mettre à jour le champ user_metadata :

Vous devez remplacer {yourAccessToken} par un jeton d’accès à la Management API.

​

Règles d’autorisation des données utilisateur

Utilisez les rules pour définir des autorisations indiquant si un utilisateur peut modifier ou non les listes de lecture en vedette.

​

Attribuer le rôle Playlist Editor

La première règle envoie une requête à notre API Node, qui interroge ensuite la base de données connectée à Heroku pour vérifier combien de fois la liste de lecture de l’utilisateur a été écoutée. Si ce nombre est de 100 ou plus, 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 indique le rôle

La deuxième Rule récupère le champ app_metadata et attribue le tableau roles à un champ de l’objet user afin qu’on puisse y accéder sans devoir appeler app_metadata dans l’application. Le paramètre scope peut ensuite préciser roles lorsque l’utilisateur se connecte, sans inclure tout le contenu de app_metadata dans l’objet user :

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 mis en place ces deux Rules, l’application reconnaît si l’utilisateur est un éditeur de playlists ou non et modifie l’écran d’accueil en conséquence. Si playlist_editor figure dans le tableau roles stocké dans app_metadata du profil de l’utilisateur, celui-ci sera accueilli comme ÉDITEUR après s’être connecté :

​

Associer les chansons d’un utilisateur à cet utilisateur

Nous devons associer les chansons d’un utilisateur à cet utilisateur, mais cette information n’est pas requise pour l’authentification. Voici comment stocker cette information dans une base de données distincte intégrée au backend de l’application.

L’identifiant unique de l’utilisateur est le user_id, et il correspond à la sous-propriété sub de l’objet idTokenPayload dans un authResult. Voici un exemple de ligne de la table songs dans notre base de données :

song_id	songname	user_id
1	Number One Hit	google-oauth2

Le backend Node.js authentifie les requêtes vers l’URI associée à la récupération des données personnelles de l’utilisateur depuis la base de données en validant un JSON Web Token.

En savoir plus sur l’authentification par jeton et sur l’implémentation des JWT dans vos applications.

Voici le code de validation des JWT tiré du projet de démarrage Node.js :

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 traiter différentes requêtes de données de notre application. Par exemple, si nous recevons une requête GET vers /secured/getFavGenre, l’API appelle la fonction queryGenre(), qui interroge la base de données et renvoie 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 en paramètres le chemin et la méthode HTTP de la requête, puis crée une requête à partir de l’URL de base de notre API Node.js, hébergée sur Heroku.

Dans l’application, la fonction getGenre() envoie une requête à l’API et modifie l’interface de l’application pour afficher la réponse à la requête envoyée à /genres/getFav. Le backend récupère les données requises pour cette action à l’aide de la fonction queryGenre(), puis 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);
    });
  });

};

​

Pour en savoir plus

• Profils d’utilisateur normalisés
• Schéma du profil d’utilisateur normalisé
• Exemples de profils d’utilisateur