Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Error: failed to deserialize user out of session" unwanted on production #6

Closed
hunterloftis opened this issue Jan 3, 2012 · 12 comments

Comments

Projects
None yet
@hunterloftis
Copy link

commented Jan 3, 2012

This is subjective but I believe a deserialization error from a bad session cookie/reset redis database/other regular production hiccup should not totally stonewall the unfortunate user with the problem. As things stand now, as soon as you get a deserialization error you're essentially blacklisted, and the error will be useless information to a typical user.

More desirable production behavior includes any of:

  1. Remove the session information and treat the user as a 'fresh' user who has not logged in
  2. Allow for a configuration option that can override this behavior (eg, gracefulFailure: true)
  3. Provide an override hook for handling failed deserializations, so the developer can at least override
@jaredhanson

This comment has been minimized.

Copy link
Owner

commented Jan 3, 2012

Agreed. I'm leaning towards option 1 as the proper fix.

@ghost ghost assigned jaredhanson Jan 3, 2012

@mwawrusch

This comment has been minimized.

Copy link

commented Jan 6, 2012

strong +1 for one.

@ktmud

This comment has been minimized.

Copy link

commented Feb 15, 2012

+10086 for this issue...

@jwyuan

This comment has been minimized.

Copy link

commented Feb 25, 2012

At least allowing the developer to handle the error would be key. +1 for at least exposing that.

@EvHaus

This comment has been minimized.

Copy link

commented Mar 14, 2012

+1 on this. Is there a workaround for the issue right now?

@thiagomagro

This comment has been minimized.

Copy link

commented Mar 23, 2012

Hello guys, any idea when this will be fixed?

@jaredhanson

This comment has been minimized.

Copy link
Owner

commented Mar 31, 2012

Fixed!

You can now invalidate an existing login session by setting user to false or null when calling done inside deserializeUser.

passport.deserializeUser(function(obj, done) {
  done(null, false);  // invalidates the existing login session.
});

Most ORMs set the result to null if the record wasn't found, as is the case with Mongoose. So, this will work as expected if you are deleting user records while they have an active session. In that case, findById sets user to null, which is passed through to Passport and the session will be invalidated.

passport.deserializeUser(function(id, done) {
  User.findById(id, function (err, user) {
    done(err, user);
  });
});

This is fixed in passport@0.1.8, which has just been published to the npm registry.

@tmfkmoney

This comment has been minimized.

Copy link

commented Sep 14, 2012

I'm having this exact same issue on version 0.1.12 with passport-facebook.

@chmanie

This comment has been minimized.

Copy link

commented Feb 16, 2014

Thank you! This should definitely find it's way into the documentation.

@cmwelsh

This comment has been minimized.

Copy link

commented Jun 1, 2014

I would note in the documentation that you have to return null or false. I tried returning undefined instead of null and came here through Google.

@tjwebb

This comment has been minimized.

Copy link

commented Oct 25, 2014

A world where null and false are the same but are not the same as undefined makes no sense. The following are true facts of Javascript:

null == false == undefined
null !== false !== undefined

Inventing your own truth table where null == false != undefined makes things unnecessarily confusing.

mvilrokx added a commit to mvilrokx/sweepstakes that referenced this issue May 31, 2016

Cleaned up some commented code from previous commit + added a feature…
… that should prevent the user ending up with a stale session using passport, see jaredhanson/passport#6 for more information, haven;t tested this though

TYoung86 pushed a commit to TYoung86/sb42 that referenced this issue Sep 5, 2016

@Luchooo

This comment has been minimized.

Copy link

commented Jan 15, 2019

This working for me, put the next following commands in your terminal:
redis-cli
select 1
FLUSHALL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.