Hey people,

Just for your information, your latest version (0.3.3) is not working for me.

I am using its simpleLocalStrategy and getting user is undefined.

so I reverted to previous release (0.2.2) which is working for me.

I'm using passportjs with expressjs 4.12 and I'm having a bad request when trying to limit access to a route.

The following code gives a bad request

router.get('/users', passport.authenticate('local'), function(req, res) {
        res.json({ currentUser: req.user });
});

But this one works and gives me the logged in user.

router.get('/users', function(req, res) {
        res.json({ currentUser: req.user });
});

What could be wrong in the setup? The login system seems to work, the user is saved in the request session, the serialize/deserialize function from passport are called when executing the second code (without the access check).

StackOverflow question here.

I've been fighting for quite awhile with this bug: immediately after the user authenticates with, say, Google, req.isAuthenticated() is returning false. I'm persisting sessions to a Postgres DB, which seems to be working fine. It's just the call to isAuthenticated which leads me to wonder if my Passport configuration might be wrong, or something.

My code for the callback looks like:

const redirects = {
  successRedirect: '/success',
  failureRedirect: '/failure'
};
app.get('/auth/google/callback', passport.authenticate('google', redirects));

My very last middleware logs the value of req.isAuthenticated(). It logs false when Google redirects back to my page, but if the user manually refreshes then it returns true.

Here are detailed logs of the logging in process:

# this is the first request to the login page. Not logged in yet.
4:59:54 PM web.1 |  -----New request-----
4:59:54 PM web.1 |  route: /login authenticated: false

# they've clicked the link to `/login`, and are immediately forwarded to Google
4:59:59 PM web.1 |  -----New request-----

# they've granted across through Google; Google redirects back to app.
# Using the Google profile, we get the user's account from the user account table
5:00:06 PM web.1 |  -----New request-----
5:00:06 PM web.1 |  about to fetch from DB
5:00:07 PM web.1 |  retrieved user from DB

# redirection to the success page...`authenticated` is false? It should now be true!
5:00:07 PM web.1 |  -----New request-----
5:00:07 PM web.1 |  route: /success authenticated: false

# here's a manual refresh...now they're showing as authenticated
5:05:34 PM web.1 |  successful deserialize
5:05:34 PM web.1 |  -----New request-----
5:05:34 PM web.1 |  route: /success authenticated: true

It looks like deserialize isn't being called when Google redirects back to my app; could that be the source of the issue?

Source code:

• Passport configuration
• Express app configuration

Passing the req object allows for greater flexibility when serializing/deserializing users. This comes in really handy when the action is altered based on the request.

For example, in my setup, depending on the domain in which the request comes through, it uses a different database configuration. Without the req object, I have no way of knowing what domain it is.

It should all be backwards compatible with existing solutions. Let me know otherwise.

Thanks for all of your work on passport!

Because the deserializeUser is treated as connect middleware and may be followed by other middleware that is listening for request events, the request stream events should be buffered until all middleware is called. Without pausing the request, middleware that pipes the incoming request (e.g. file upload, body parsing, proxy middleware, etc.) may miss data or end events.

Hey :wave:

Passport.js still remains the recommended way by many to implement authentication in Node.js applications. There are a lot of businesses that rely on this and there are also a lot of newcomers to Node being directed to this library by various videos and blog articles.

I noticed that there hasn't been a commit in 7 months and this has led me to wonder about the future of the project.

There are currently, as of writing, 308 open issues and 30 open pull requests. Quite a few of these issues and pull requests span back months or years and many don't have any responses.

I understand maintaining an open source library of this size and importance is tiresome work but I just wonder what the plans are for the future? How should we collectively go about triaging these issues and working our way through the open PRs?

Is there also work to be done on improving the documentation for the project? Last time I implemented Passport.js in a project I stumbled across this alternate manual, the existence of this probably indicates the official documentation could do with some work.

I also found similar sentiment in the /r/node Reddit thread about the alternate documentation.

Thanks, Luke

Hi,

Maximum strangeness. The latest version on npm is 0.5.1 with breaking changes (e.g. req._passport isn't defined, and therefore we got 'middleware not in use' related errors as-of-today's recent builds).

Can someone take a look at this urgently please, before more people are affected?

Thanks, John

I have set up passport to use a custom authentication scheme, but for arguments sake, imagine it authenticates any user to the app. I have a 'landing' page with a login button that issues a post, handled as follows:

app.post('/:id/landing', function (req, res, next) {
  passport.authenticate('myAuth', function (err, user) {
    if (err || !user) {
      return res.redirect('/' + req.params.id + '/landing' + req.body.redirectTo);
    } else {
      req.logIn(user, function () {
        return res.redirect('/' + req.params.id + '/' + req.body.redirectTo);
      });
    }
  })(req, res, next);
});

later, a route handler matches the redirect:

app.all('/:id/', function (req, res) {
  if (req.isAuthenticated()) {
    res.sendFile('index.html', {root: __dirname + '/../frontend/'});
  } else {
    // Instead of redirecting to /landing, simply render it.
    // this gets round safari issue with losing url fragments during a redirect:
    // https://bugs.webkit.org/show_bug.cgi?id=24175
    //
    res.render('landing', {message: '', previousID: '/' + req.params.id});
  }
});

9 times out of ten, this all works fine, but occasionally req.isAuthenticated will return false. If I put some logging in, I can see that before the redirect I have a valid req.user object, but then in the second route handler following the redirect, req.user is undefined. Sometimes it works, sometimes it doesn't! (When it does work, req.user IS defined in the second route handler) Is this issue the same as others have reported around the user not being serialised correctly?

In expressjs 4.6.1 I am getting this deprecation warning:

"express deprecated res.redirect(ur, status): Use res.redirect(status, url) instead node_modules/passport/lib/middleware/authenticate.js:294:15"

So I fixed it for you! ;)

Note: my editor also removed excess spaces automatically - sorry about all the changes below - line 294 is the only real change.

I'm using passport-local. I have a logout method that calls req.logout to end the session. The problem is it doesn't clear req.session so connect saves a bogus session entry to redis when req.send is called:

Before logout:

1. "{"cookie":{"originalMaxAge":259200000,"expires":"2014-03-21T22:03:55.265Z","httpOnly":true,"path":"/"},"passport":{"user":"bn"}}"

After logout:

1. "{"cookie":{"originalMaxAge":259200000,"expires":"2014-03-21T22:04:01.148Z","httpOnly":true,"path":"/"},"passport":{}}"

Is this something we're expected to take care of ourselves?

I'm using Passport to log in with Facebook or Twitter into my service. Since MemoryStore is not intended for production and I'm not going to store much information into the session, I wanted to use cookieSession, but it doesn't work:

app.use(express.bodyParser());
app.use(express.methodOverride());
app.use(express.cookieParser());
app.use(express.cookieSession({ secret: 'keyboard cat', cookie: {maxAge: 60 * 60} }));
app.use(passport.initialize());
app.use(passport.session());
app.use(app.router);

It works as expected if I repace cookieSession() with session():

app.use(express.session({ secret: 'keyboard cat' }));

When using NestJS and Passport to authenticate users, SAML will always be chosen as the first strategy. I'm providing passport several strategies as a fallback, but if SAML is somewhere in that array, it will always be the first to be checked.

Expected behavior

I expect that Passport will try to use the provided stragies in the order they are passed.

Actual behavior

If saml is somewhere defined in the array of strategies passed on to passport. The saml strategy will always be the first to be tried, regardless of the actual position in the passed array. It can be defined as the last strategy in the array and it will still be the first strategy to be tried.

Steps to reproduce

1. Use NestJS and Passport for authentication
2. Create SAML Strategy
3. Provide passport basic and saml as a strategy
4. Start the authentication process
5. Notice that you will be redirected to SAML accessUrl

Environment

Environment

Node.js version: 18.10.0 passport version: ^0.4.1

Hi Team,

When I upgrade my passport version 0.4.0 to 0.6.0 my service deployment getting failed in AWS. Getting 500 error code and unhealthy in target group.

I am getting "Error: failed to deserialize user out of session" - the problem is that this generates 500 server error and I can't present a nice page to the user to say "please log in again". How can I work around this?

The issue is related to https://github.com/LaunchAcademy/generator-engage/issues/122 and https://github.com/jaredhanson/passport/issues/6 - what happens is that I have a bad cookie with User ID that does not exist. In deserializeUser my function User.findOne correctly returns an error and I pass this to Passport's done/callback with false as others have done before me. But Passport still creates a 500 error instead of redirecting back to the login page. I guess I could do some sort of a hack and try to clear the cookie in the deserializeUser but feels hacky.

What is the way to solve this? Is there a way to instruct Passport to forward the request back to the login page in case of an error in deserializeUser rather than generate server error 500?? It's not that 500 is ugly but it also prevents user from logging on until the cookie is cleared manually.

My code below for reference

passport.deserializeUser(function(user, cb) {
  process.nextTick(async function() { 
    var usr = false;
    usr = await User.findOne(null, user.id)
      .catch(err => 
        cb(err, false)); // this gets triggered by User.findOne as the user.id is non-existent in the DB
    return cb(null, usr || false);
  });
});

I have tried returning cb(err) or cb(err, null) etc but none worked

Are you looking for help? Yes

Is this a security issue? No

I set the socketId to session before authorizing the user but after .login() was called on the passport, the socketId is deleted and every other part of the session object was rewritten ( It seems passports is trying to create session object again with it's own related data).

I use passport, passport-google, and passport-local to provide simple authentication on nestjs. I set the socketId on middleware to announce the user after the authorization, process is done and close the google auth window on client.

Expected behavior

On version 0.4.1 The socketId still exists after user is logged in and I can notify user that you are authenticated but in this version socketId does not exists or any other session data that had been added before login.

Steps to reproduce

For reproduction you need to upgrade the Passport to version 6.0.0 and set any data to session.

Before the .login() method call thissession looks like:

cookie:  {path: '/', _expires: Mon Dec 20 2040 21:39:35 GMT+0400 (GMT+04:00), originalMaxAge: 3000000000000, httpOnly: true}
test: 'Monaliza'
socketId: 'Ejy-bm0QelhLvS7jAAAB'
id: '0513aa87-2376-4f42-b42e-f3fb2fb3540b'

After the .login() method call session looks like:

cookie: {path: '/', _expires: Mon Dec 20 2117 21:42:15 GMT+0400 (GMT+04:00), originalMaxAge: 3000000000000, httpOnly: true}
passport: {user: 1}
id: dca6-4a00-8840-d4ff4e392355'

I checked every dependency problem and I'm sure problem is related to the Passport.

Environment

• Operating System: Linux, ubuntu 20.04
• Node version: 16.15.1
• passport version: 0.6.0
• NestJs version: 8.x
• Related packages: [email protected] & [email protected]
• express-session store: [email protected]
• Redis client: [email protected]

Background RE: #904

Using [email protected], [email protected] with the [email protected] module to login with Github, the application throws the following error message:

TypeError: req.session.regenerate is not a function at SessionManager.logIn

Feature

Utilize the Delegate Pattern and default to an empty implementation so that the code does not throw an error.

Checklist

• [ x ] I have read the CONTRIBUTING guidelines.
• [ x ] I have added test cases which verify the correct operation of this feature or patch.
• [ x ] I have added documentation pertaining to this feature or patch.
• [ x ] The automated test suite ($ make test) executes successfully.
• [ x ] The automated code linting ($ make lint) executes successfully. (NOTE: Lint errors are with code not touched by this PR)