Accounts-merge vs. accounts-meld

help
1

I’m wondering what the similarities & differences are between @splendido 's “Accounts Meld” and @mikael 's “Accounts Merge” ?


At first glance, they both seem allow a single account to have multiple logins (social and/or email/password). I’m wondering if anyone has had any experience with these packages to provide any advice or insight on which may be better suited for a new project.

thank you!

3 Likes
2

I’m not sure what you need your project to do but I have been rolling my own account merging for my personal projects. I feel like I get more control when it comes to dealing with the different services that I want incorporated into my apps. I have no experience with these packages but here is a link to a stack overflow question from a while ago that would tell you how to handle your own if you wanted.

And here is the relevant code snippet.

orig_updateOrCreateUserFromExternalService = Accounts.updateOrCreateUserFromExternalService;
Accounts.updateOrCreateUserFromExternalService = function(serviceName, serviceData, options) {
  var loggedInUser = Meteor.user();
  if(loggedInUser && typeof(loggedInUser.services[serviceName]) === "undefined") {
    var setAttr = {};
    setAttr["services." + serviceName] = serviceData;
    Meteor.users.update(loggedInUser._id, {$set: setAttr});
}
return orig_updateOrCreateUserFromExternalService.apply(this, arguments);
}
3 Likes
3

I’m using splendido:accounts-meld - working like a charm. Users can’t create multiple accounts with the same e-mail.

4

Ok, I’m the author of accounts-meld, so my point of view might be a little biased :wink:

I wrote accounts-meld after I studied accounts-merge quite well: at that time the bigger problem I found was this security issue. I have no idea whether lirbank fixed it later on or not but I strongly suggest anyone interested to check it again!

This said accounts-meld have been around for a while and prooved to by quite good.
The only weakness is that it has no way to detect duplicate accounts for all those OAuth services which do not provide an email address for the user (e.g. Twitter…).

Then you get a number of hooks to deal with user’s documents migration and the like in case of automatic merges, etc.
Lets try it in action!

I have plans to integrate accounts-meld into useraccounts v2.0 but this won’t be ready before a couple of months

5 Likes
5

Thanks @splendido !

I had not seen useraccounts before, and was just looking at how to customize the accounts templates. Thanks for this!

I guess you will be integrating accounts-meld into useraccounts in meteor-useraccounts/meld ? Or were you planning to do that work in the existing accounts-meld repository?

Regarding this:

The only weakness is that it has no way to detect duplicate accounts for all those OAuth services which do not provide an email address for the user (e.g. Twitter…).

Though maybe not optimal UX, I have seen some sites require all users to provide an email and a password. Would work like this:

  1. User’s 1st time to the site – they choose to log in using OAuth service 1 which provides a verified email
  2. The site presents a form showing the imported data from the OAuth service 1, asks the user to confirm/update their data, and provide a password
  3. User account is created, User has a happy experience, logs out…
  4. (…time passes…)
  5. User returns the the site – they choose to log in using OAuth service 2 (forgot they used OAuth service 1 before)
  6. The site receives no email address from OAuth service 2
  7. The site presents a form showing the imported data from the OAuth service 2, asks the user to confirm/update their data, and provide email and password.
  8. User enters email of existing account and correct password
  9. User gets authenticated, OAuth service 2 is now melded. In the future the User can log in with email/password, OAuth service 1 or OAuth service 2

It’s not so optimal UX to require the user to provide the email/password. However, the steps 2 & 7 above allow the User to confirm their imported info before proceeding, which may be nice.

As an alternative:

  1. User’s 1st time to the site – they choose to log in using OAuth service 1 which provides a verified email
  2. User account is created, User has a happy experience, logs out…
  3. (…time passes…)
  4. User returns the the site – they choose to log in using OAuth service 2 (forgot they used OAuth service 1 before)
  5. The site receives no email address from OAuth service 2
  6. The site asks the user to provide an email
  7. User provides the same email which OAuth service 1 sent in step 1
  8. The site presents something like: “Please log in with OAuth service 1 to meld OAuth service 2 with it”

I’m curious your thoughts on these two approaches.

2 Likes
6

Your second scenario seems to provide a little better experience.
Any way at step 7 you should send out a verification emal to be sure the user is typing in her own email.
Once she click the verification link on the email you can proceed with accounts melding and at the next login she’ll possibly discover she already had some data on the site…

Does this makes sense?

7

Absolutely – that’s correct!

8

God had no idea it was available there (Meteor.user()).

9

Do either of these packages still work?

1 Like