examples/express2/auth.js
function(requestToken, done) {
    db.requestTokens.find(requestToken, function(err, token) {
      if (err) { return done(err); }
      
      var info = { verifier: token.verifier,
        clientID: token.clientID,
        userID: token.userID,
        approved: token.approved
      }
      done(null, token.secret, info);
    });
  }
function(requestToken, done) {
    db.requestTokens.find(requestToken, function(err, token) {
      if (err) { return done(err); }
      
      var info = { verifier: token.verifier,
        clientID: token.clientID,
        userID: token.userID,
        approved: token.approved
      }
      done(null, token.secret, info);
    });
  }
function ( requestToken , done ) { db . requestTokens . find ( requestToken , function ( err , token ) { if ( err ) { return done ( err ) ; } var info = { verifier : token . verifier , clientID : token . clientID , userID : token . userID , approved : token . approved } done ( null , token . secret , info ) ; } ) ; }
token callback  This callback finds the request token identified by `requestToken`.  This is typically only invoked when a client is exchanging a request token for an access token.  The `done` callback accepts the corresponding token secret as the second argument.  The `ConsumerStrategy` will use this secret to validate the request signature, failing authentication if it does not match.  Furthermore, additional arbitrary `info` can be passed as the third argument to the callback.  A request token will often have associated details such as the user who approved it, scope of access, etc.  These details can be retrieved from the database during this step.  They will then be made available by Passport at `req.authInfo` and carried through to other middleware and request handlers, avoiding the need to do additional unnecessary queries to the database.
token callback This callback finds the request token identified by requestToken . This is typically only invoked when a client is exchanging a request token for an access token . The done callback accepts the corresponding token secret as the second argument . The ConsumerStrategy will use this secret to validate the request signature failing authentication if it does not match . Furthermore additional arbitrary info can be passed as the third argument to the callback . A request token will often have associated details such as the user who approved it scope of access etc . These details can be retrieved from the database during this step . They will then be made available by Passport at req . authInfo and carried through to other middleware and request handlers avoiding the need to do additional unnecessary queries to the database .