web-dev-qa-db-fra.com

Quelle est la meilleure façon d'implémenter les rôles et les autorisations dans Express REST Api

J'ai besoin d'une sorte d'expertise pour implémenter les rôles et les autorisations dans Express js. Je prévois de développer Restful Api en utilisant Express js, mais je n'ai pas obtenu suffisamment d'informations pour implémenter les rôles et les autorisations, bien qu'il existe des tonnes d'options disponibles pour l'authentification et l'autorisation.

node.jsrestexpress
17
zahid rasool

Créer des tableaux

Vous devez d'abord créer vos tables qui contiendront les associations entre les rôles, les autorisations et les ressources:

  1. Créer une table des rôles ('Admin', 'Utilisateur', 'Invité')
  2. Créer une table de ressources ('Utilisateurs', 'Projets', 'Programmes')
  3. Créez une table d'autorisations ('Créer', 'Lire', 'Écrire', 'Supprimer', 'Refuser')
  4. Créer une table de jonction avec les trois tables comme sources

Vous n'avez peut-être pas besoin de ce type de granularité pour la table des autorisations, mais certaines personnes l'aiment. Par exemple, vous n'avez pas vraiment besoin de "Refuser", car vous vérifiez simplement Read! = True.

Maintenant, lorsque vous voulez les autorisations d'un rôle sur une ressource, il vous suffit de rechercher role_id et resource_id et de vérifier quelles autorisations sont définies sur true.

Créer un middleware

Puisque vous utilisez express, le middleware sera facile à ajouter. Par exemple, supposons que vous ayez un routeur appelé utilisateurs:

users.post('/', getAuth, handleUserPost)

En supposant que vous ayez un jeton quelconque sur la demande qui identifie l'utilisateur effectuant la publication, et en attachant l'instance d'utilisateur à l'objet de demande, vous pouvez le faire:

getAuth = function (req, res, next) {
  if(req.user) { 
    db.getPerms({role_id: req.user.role_id, resource_id: req.resource.id})
       .then(function(perms){
          var allow = false;
          //you can do this mapping of methods to permissions before the db call and just get the specific permission you want. 
          perms.forEach(function(perm){
              if (req.method == "POST" && perms.create) allow = true;
              else if (req.method == "GET" && perms.read) allow = true;
              else if (req.method == "PUT" && perms.write) allow = true;
              else if (req.method == "DELETE" && perm.delete) allow = true;

          })
          if (allow) next();
          else res.status(403).send({error: 'access denied'});
       })//handle your reject and catch here
   } else res.status(400).send({error: 'invalid token'})
}

Ce code a été ébauché juste pour cet exemple, donc je n'irais pas copier et coller, mais il devrait vous donner la bonne idée.

20
Dave Briand

Droits de rôle dans Node.js

Partie 1: Qu'est-ce que le rôle et les droits?

La mise en œuvre des droits de rôle est une partie importante de tout logiciel.Le rôle est une position de responsabilité et chaque responsabilité jouit de certains droits qui leur sont accordés.Il peut y avoir des droits communs entre quelques rôles et certains droits peuvent appartenir strictement à un rôle spécifique.

Les droits sont des URL auxquelles un rôle est autorisé à accéder.Il est donc nécessaire de créer une collection dans db stockant des informations sur les droits d'un rôle. Nous avons un schéma de collecte de rôles comme

const mongoose = require('mongoose');
const Schema = mongoose.Schema;
const RoleSchema = new Schema({
roleId:{
type:String,
unique:true,
required:[true,"Role Id required"]
},
type:{
type:String,
unique:true,
required:[true,"Role type is required"]
},
rights:[{
name: String,
path: String,
url: String
}]
});
module.exports = Role = mongoose.model('role',RoleSchema);

N'oubliez pas que chaque rôle supposé exister se trouve dans la collection de rôles et du type de schéma ci-dessus.

Dans le tableau des droits de schéma de l'objet, nous voyons que l'objet a des clés:

  • nom (pour le nom de l'URL comme "set-username")
  • chemin (pour le chemin de base, appuyez sur "/ utilisateurs /")
  • rl (URL demandée ou chemin complet "/ users/set-username")

Ainsi, si un utilisateur ayant un rôle utilisateur a le droit de changer de nom d'utilisateur, il peut appuyer sur url /users/set-username. Cependant, un vagabond ne pourra pas accéder à cette URL. Un rôle supérieur comme admin et superadmin devrait logiquement avoir accès à tous les droits de rôle inférieurs (URL).

Les rôles dans une application réelle sont: -

  1. Wanderer ( Quelqu'un qui vient de visiter notre site.Il devrait pouvoir accéder à tous les itinéraires publics.Les URL simples/URL publiques accessibles à tous n'ont donc pas besoin de faire un rôle distinct pour cela car ce n'est pas un droit authentifié. )
  2. Invité ( Une personne qui s'est inscrite mais qui n'a pas vérifié dit que l'e-mail n'est pas vérifié ).
  3. tilisateur ( Quelqu'un qui a son email vérifié )
  4. Admin ( A fait un administrateur par SuperAdmin après vérification.il jouit de la plupart des droits )
  5. Superadmin ( Maître de l'application.Il bénéficie de droits plus sophistiqués.Plus de droits que l'administrateur )

Jusqu'à présent, nous avons compris ce qui est parfaitement juste et comment il est associé à un rôle.

Partie 1.5: URL enregistrées/URL de configuration

Ici, nous avons un fichier appelé registeredUrls.js qui est comme:

module.exports = {
    simple:{
        "/":[""],
        '/users/':["login","register"],
    },
    auth:{
        //admin
        '/admin/': ['load-users' , 'set-new-password','delete-user'],
        '/teacher/':["add-teacher","delete-teacher","edit-teacher"],
        '/student/':["add-student","delete-student","edit-student","test-result"],

        //user
        '/test/':["view-test","submit-test"],
        '/profile/': ['change-username', 'update-profile-data',  'set-new-password', 'upload-pic', 'update-social-links'],
        '/teacher/':['load-teacher'],
        '/student/':['load-student']

    }
}

De même confgUrls.js

const configUrls= {
    '/roles/': ['get-rights', 'create', 'update-rights', 'load', 'delete', 'assign']
}
module.exports = configUrls;

Partie 2: Création de SuperAdmin

C'est la partie la plus essentielle de l'application.Lorsque le serveur démarre pour la première fois ou redémarre/redémarre, cette étape se produit.Dans config/init.js, suivez la procédure:

  1. Chargez toutes les URL simples (publiques) et les URL d'authentification (admin et utilisateurs) et les URL spécifiques aux super-administrateurs dans superAdminRights [].
  2. Exécutez ensuite une fonction pour créer un utilisateur avec le rôle superadmin s'il n'existe pas.
  3. Obtenez un rôle de type: "superadmin" s'il est trouvé: remplacez ses droits par de nouveaux droits (superAdminRights) .else: créez un rôle de type: "superadmin" puis remplissez ses droits (superAdminRights).

À la fin de cet appel de fonction, nous sommes toujours sûrs d'avoir un superadmin en application avec toutes ses URL/droits sophistiqués initialisés.

Partie 3: URL spécifiques au super-administrateur

Ce sont des droits dont jouit uniquement le super administrateur et qui doivent être conservés dans le fichier séparé en parallèle au fichier URL enregistré, notamment les droits URL qui mappent les itinéraires utilisés uniquement par le superadmin. Ici, nous avons des itinéraires pour créer un rôle, charger des rôles, obtenir des droits pour un roleId, mettre à jour des droits pour roleId/type de rôle, attribuer un rôle à un utilisateur, supprimer un rôle.

Pour chaque utilisateur dans le code, nous devons changer leur rôle d'invité en utilisateur (par exemple, après vérification par e-mail). Ou invité/utilisateur à admin par superadmin en utilisant l'URL assign-role. Ensuite, la mise à jour des droits d'administrateur à l'aide de route update-rights.

Le processus garantit que chaque rôle possède un document de collection et des droits qui s'y trouvent.

Partie 4: middleware d'authentificateur

Ce coeur de notre RBACS logique. Ici, nous utilisons un middleware qui suit le processus:

1. Remplissez toutes les URL d'authentification requises dans un [AUTH_URLS] avec des auth-urls (registeredUrls.js) et des super-admin-specific-urls (confgUrls.js) et une simple URL dans différents [SIMPLE_URLS].

2. Ensuite, vérifiez si (AUTH_URLS.indexOf (request.url)> -1) {3ème étape} sinon si (SIMPLE_URLS.indexOf (request.url)> - 1) {alors c'est l'url publique si simple autorisez next ()} else { URL de réponse inconnue}

3. Dans cette étape, nous savons que l'URL demandée dans AUTH_URLS nécessitait donc une vérification de jeton pour l'en-tête de jeton d'autorisation s'il est trouvé, puis en extraire le jeton puis {4ème étape} .si aucun en-tête d'autorisation n'a trouvé la réponse "jeton requis"/"inconnu".

4. Jeton trouvé, vérifiez maintenant que ce jeton a une session valide.Si oui {5ème étape} autre session de jeton non trouvée, connectez-vous à nouveau. 5. valider le jeton jwt en le vérifiant s'il est vérifié {6. étape} sinon réponse "jeton jwt non valide".

6.jusqu'à présent, l'URL demandée est correcte et la session de jeton existe et le jeton valide jwt.Maintenant, en utilisant les informations de type rôle de la session (stockées dans la session sont les informations de base de l'utilisateur et du jeton) trouver dans Rôle pour cela type de rôle de session utilisateur, nous avons donc ses droits []. Voyons maintenant si le request.url est inclus dans les droits []. s'il est trouvé {7ème étape} else {reponse "rôle non trouvé/utilisateur inconnu"}.

7. si trouvé alors {a accès à cette url next ()} else {réponse "accès refusé"}

3
Aniket Jha