unrecognized password after mongorestore about passport-local-mongoose HOT 10 CLOSED

This sounds really strange. What else did change? Node version? Could you check if the data contained in hash and salt field of the user model have the same value

from passport-local-mongoose.

Hey, we got the same problem and I traced it to here. Depending on NODE_ENV crypto.pbkdf2.length returns different values - 6 for "development" and 0 for "production". Super weird.

@saintedlama can you please tell us why do you need to perform this check?

from passport-local-mongoose.

It turned out for us that there is no link to NODE_ENV. It was newrelic. Just requiring it somehow sets crypto.pbkdf2.length to 0 😮
I guess if @remotevision confirms he had newrelic on prod too this issue can be closed.

from passport-local-mongoose.

@evindor Thanks for digging that deep to find the bug. Changed behavior in passport-local-mongoose to detect pbkdf2 based on node versions instead of argument length. Released on NPM as 3.1.1

from passport-local-mongoose.

@saintedlama Thanks for quick reaction! But I think you need to unpublish 3.1.1 ASAP and republish it bumping major or at least minor version - this is a breaking change for everyone using newrelic in production. Because in fact this is release 3.0 (setting default algo to sha256) for people using newrelic.

The issue is very stealthy and if someone deploys today they might lock their users out without realizing it.

from passport-local-mongoose.

Thanks for the hint! It was a bug fix mentally 😢 - republished a patch level reverted pkg to ensure everyone will get the fix. Will bump major.

from passport-local-mongoose.

👍

from passport-local-mongoose.

@remotevision Can you confirm this newrelic thingy?

from passport-local-mongoose.

I do use New Relic!

from passport-local-mongoose.

@remotevision Then I'll suggest to switch to version 4 of passport-local-mongoose. Thanks all for sorting out that issue 🎉

from passport-local-mongoose.