So I am migrating our app from Meteor to Express (I know that’s a can of worms, but this post is not about that). I am trying to use Auth0 as a user authentication strategy. We have existing users, so I need to use our MongoDB users created by Meteor. Now, Auth0’s MongoDB config has something like this to log in users, but it doesn’t work against the Meteor Accounts bcrypt token. Any ideas on how to validate the user.services.password.bcrypt token? I figure someone would be able to save me a ton of work combing through the Accounts repo.
Thanks!
var users = db.collection('users');
users.findOne({ "emails.0.address": email }, function (err, user) {
console.log('USER', user, err, email, password);
if (err) return callback(err);
if (!user) return callback(new WrongUsernameOrPasswordError(email));
bcrypt.compare(password, user.services.password.bcrypt, function (err, isValid) {
console.log('IS VALID', isValid);
if (err) {
callback(err);
} else if (!isValid) {
callback(new WrongUsernameOrPasswordError(email));
} else {
callback(null, user);
}
});
It looks like Meteor is first using sha256 on the plain-text password, so I thought that if I did that and called bcrypt.compareSync(password, dbHashedPwd), that it would work. Could really use some suggestions…
So it works, if you use a sha256 package to hash the plain-text password, and then send it to Auth0. Turns out I was checking the sha256 against a different user’s password so it seemed to be even more confusing!
Looking into migrating Meteor Accounts for our project soon too. A problem I ran into recently when trying to setup a custom password-setting function, was that our build system blew up when I tried to use bcrypt to hash the digest on the server.
Meteor uses a native version of bcrypt for performance reasons, but that means using node-gyp to integrate native extensions into the node server they bundle. I didn’t want to get into integrating the native bcrypt, so we opted for bcryptjs which has the same API and is available through npm (although it is 3x slower than the native implementation and Meteor lets you know that.)
We’ll be looking at moving to Auth0 soon as well, so I look forward to seeing your progress through the migration. Good Luck!
Hi guys, we’ve done it already, a few months ago. @wallslide here did the work. I’m looping him in in case he feels like sharing any code. There was an official Auth0 Meteor boilerplate repo, but there was a security hole in their code. After it was reported, instead of fixing it, they just took down the repo
We integrated Auth0 with two apps (which share the user database) and had existing users, and we use some advance features like custom fields on signup. It was much more work than we expected, and still it’s not working 100%. We have some issue where our users cannot change their own email address which we’re still investigating.
I hate to see people reinvent the wheel, but @wallslide knows his way around the code better than I.
Hi @maxhodges, thanks for the response. Glad to know others have gone this route too. Login seems to be working fine. I guess the security issue would be that the sample script for MongoDB has to be modified to not send over sensitive information? I plan on talking to Auth0 more, but any pointers and suggestions are very welcome. I’ll also continue to post to this thread if I discover anything useful. Cheers!
sure but we are both in Japan timezone. I’ll have a little time from 11AM (JST) if you want me to send a google hangout invite then http://everytimezone.com/
btw there is a personal message section here on meteor forums for things like email address exchange. Just click someone’s name, then you should see the “Message” button. There you can send private messages.
How are you guys querying for users by their id’s now that Auth0 generates them for you? I reeeaally want to avoid having to create a migration script.
I’ve tried using the Custom Database method and found that setting “user_id” in the callback would create Auth0 profiles with the “[provider]|”[meteorUserId]"" signature. This would be alright, since I would be able to filter out the provider and return just the meteorUserId and continue querying other collections without having to update legacy documents. Though this comes with very troublesome housekeeping and overall not a very good architecture. If I wanted to query for multiple users, or any user at all from Auth0’s API, I would need to prefix my userId with multiple providers before fetching the correct document. I would also have to query my mongo database to fetch all users that have not yet been imported into Auth0’s database.
I’ve also tried the bulk import approach but found that I’ve ran into similar issues. Their api implementation is a bit different, which prevents me from created Auth0 profiles with the “[provider]|[meteorUserId]” signature. So I’m able to curve having to query both user collections, but left with the option of being forced to write a migration script so that my other mongo collections have Auth0’s user ids.
