Anyone has experience moving meteor users to firebase?

help
1

Hi,

I’m considering moving an app from meteor to firebase for authentication, due to their otp system and a few more things. Meteor stores passwords by hashing them with sha256 before encrypting them with bcrypt. Firebase seems to provide both the algorithms individually, but no combination of the two.

Does anyone have any experience trying to migrate meteor users to firebase? Did you have to force password reset?

2

Hi asad,
I know it’s a pretty old question but I’m facing the same challenge. Did you manage to migrate your users from Meteor to Firebase while keeping their passwords?
Thanks a lot.

3

Answering my own question.

Looks like it works this way:

Let’s take something from My Meteor Mongo users collection:

"services" : {
  "password" : {
    "bcrypt" : "$2a$10$/fhnbcgV7zTXpW5RrZmntO69cY4kFv6YZiDaeE3b66bkSwOU5I1ES"
  },
}

Let’s import this user to Firebase (with the admin SDK):

// Up to 1000 users can be imported at once.
const userRecords = [
  {
    uid: 'uid2',
    email: 'user2@example.com',
    passwordHash: Buffer.from('$2a$10$/fhnbcgV7zTXpW5RrZmntO69cY4kFv6YZiDaeE3b66bkSwOU5I1ES'),
  },
]

admin.auth().importUsers(
  userRecords,
  {
    hash: {
      algorithm: 'BCRYPT'
    }
  },
)
  .then(userImportResult => ...)
  .catch(error => ...)

Let’s check in the Firebase console that it worked. Ok.

And then finally from the client side:

import hash from 'hash.js'

const hashedPassword = hash.sha256().update(password).digest('hex')
firebase.auth().signInWithEmailAndPassword(login, hashedPassword)
  .then(result =>  ...)
  .catch(error => ...)

Signin is successful!

It is a bit annoying to have to hash the password before trying to authenticate with Firebase, but moving to another auth’ system and not having to reset user’s password is a much higher advantage to me.

4 Likes
4

What’s the reason behind the switch? Is it just auth or moving over entirely?

5

Ultimately that would be to move over entirely, for plenty of reasons discussed elsewhere. (Gain more control over our stack, a more state-of-the-art frontend app and move away from deprecated packages, be better prepared for scaling, etc…) Why this question? :slightly_smiling_face: