Passport-http-bearer: Comment fonctionnent les portées ?

Créé le 5 mars 2012 · 3Commentaires · Source: jaredhanson/passport-http-bearer

Salut Jared,

J'ai du mal à comprendre comment le passeport traite les champs d'application. Voici mon scénario :

J'ai un magasin de jetons, chaque jeton a une portée qui lui est attachée. J'ai certaines routes auxquelles seuls les jetons avec une portée d'administrateur peuvent accéder et d'autres qui nécessitent un accès normal aux jetons. Dans mon application, je ferais quelque chose comme ceci:

app.use('/v1', passeport.authenticate('porteur', { session : false }) :

pour attraper le cas normal et pour des routes spécifiques qui nécessitent des droits d'administrateur, j'ajouterais quelque chose comme ça dans le middleware de la route, comme
.. passeport.authenticate('porteur', { session : faux, étendues : ['admin']})

Est-ce soutenu par un passeport ou dois-je le faire différemment?

Source

mwawrusch

Commentaire le plus utile

@mwawrusch J'ai une solution à cela qui me satisfait et qui fonctionne bien, qui est une version légèrement nettoyée de ce que vous mentionnez.

Vous pouvez maintenant passer un troisième argument au succès, et qui est attaché par Passport à req.authInfo

passport.use(new BearerStrategy(
  function(token, done) {
    User.findOne({ token: token }, function (err, user) {
      if (err) { return done(err); }
      if (!user) { return done(null, false); }
      return done(null, user, { scope: 'profile' });
    });
  }
));

L'argument info peut ensuite être utilisé dans le middleware plus loin dans la chaîne pour implémenter l'autorisation et le contrôle d'accès.

app.get('/api/userinfo', 
  passport.authenticate('bearer', { session: false }),
  function(req, res, next) {
    // access control middleware to check for required scope
    if (req.authInfo.scope != 'profile') {
      res.statusCode = 403;
      return res.end('Forbidden');
    }
    return next();
  }
  function(req, res) {
    res.json(req.user);
  });

Le info n'est qu'un objet JSON générique, l'application devra donc se contenter de conventions pour ce qui est fourni. J'espère que cela s'avérera également utile pour la mise en œuvre d'intergiciels d'autorisation à usage général.

La fonctionnalité coïncide avec le développement de OAuthorize et OAuth2orize , qui l'utilisent. Ils peuvent être utilisés pour implémenter respectivement les serveurs OAuth 1.0 et 2.0. Je pense avoir vu une page Quora sur ce sujet que vous avez créée. Ce serait bien de les ajouter à ça!

Comme toujours, envoyez-moi vos commentaires. Acclamations!

jaredhanson le 13 juil. 2012

👍4

Tous les 3 commentaires

Juste pour être complet, voici ce que je fais maintenant : j'ajoute simplement les portées à l'objet utilisateur et j'utilise req.user... et à un stade ultérieur, je vérifie si la route et la portée spécifiques correspondent.

mwawrusch le 21 mars 2012

@mwawrusch J'ai une solution à cela qui me satisfait et qui fonctionne bien, qui est une version légèrement nettoyée de ce que vous mentionnez.

Vous pouvez maintenant passer un troisième argument au succès, et qui est attaché par Passport à req.authInfo

passport.use(new BearerStrategy(
  function(token, done) {
    User.findOne({ token: token }, function (err, user) {
      if (err) { return done(err); }
      if (!user) { return done(null, false); }
      return done(null, user, { scope: 'profile' });
    });
  }
));

L'argument info peut ensuite être utilisé dans le middleware plus loin dans la chaîne pour implémenter l'autorisation et le contrôle d'accès.

app.get('/api/userinfo', 
  passport.authenticate('bearer', { session: false }),
  function(req, res, next) {
    // access control middleware to check for required scope
    if (req.authInfo.scope != 'profile') {
      res.statusCode = 403;
      return res.end('Forbidden');
    }
    return next();
  }
  function(req, res) {
    res.json(req.user);
  });

Comme toujours, envoyez-moi vos commentaires. Acclamations!

jaredhanson le 13 juil. 2012

👍4

Très bien merci.

Le ven. 13 juillet 2012 à 8 h 36, Jared Hanson <
ré[email protected]

a écrit:
@mwawrusch J'ai une solution à cela qui me satisfait et qui fonctionne
bien, qui est une version légèrement nettoyée de ce que vous mentionnez.
Vous pouvez maintenant passer un troisième argument au succès, et qui est attaché par
Passeport à req.authInfo
passport.use(new BearerStrategy(
  function(token, done) {
    User.findOne({ token: token }, function (err, user) {
      if (err) { return done(err); }
      if (!user) { return done(null, false); }
      return done(null, user, { scope: 'profile' });
    });
  }
));
L'argument info peut ensuite être utilisé dans le middleware plus bas dans la chaîne pour
mettre en œuvre l'autorisation et le contrôle d'accès.
app.get('/api/userinfo',
  passport.authenticate('bearer', { session: false }),
  function(req, res, next) {
    // access control middleware to check for required scope
    if (req.authInfo.scope != 'profile') {
      res.statusCode = 403;
      return res.end('Forbidden');
    }
    return next();
  }
  function(req, res) {
    res.json(req.user);
  });
Le info est juste un objet JSON générique, donc l'application devra régler
sur les conventions pour ce qui est fourni. J'espère que cela prouvera
utile également pour implémenter un middleware d'autorisation à usage général.
La fonctionnalité coïncide avec le développement de OAuthorize et OAuth2orize , qui l'utilisent. Ils
peut être utilisé pour implémenter respectivement les serveurs OAuth 1.0 et 2.0. je pense
J'ai vu une page Quora sur ce sujet que vous avez créée. Ce serait génial de
ajoutez-les à cela !
Comme toujours, envoyez-moi vos commentaires. Acclamations!
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/jaredhanson/passport-http-bearer/issues/2#issuecomment -6966368