Add Meteor.connectWith<Service> for services used by app

[zimme]

This is to prevent another account from logging in when you wanna add a service to the currently logged in account and there already are another meteor account which has this service.

With Meteor.loginWith<service> that account will be logged in.

[splendido]

This would somehow require the UI logic to distinguish between the two calls loginWith<service> and connectWith<service> which is something I'd prefer to avoid...

This was achieved, e.g., using Accounts.updateOrCreateUserFromExternalService in splendido:accounts-meld but I'm not pretending that's the best solution!

[zimme]

This could probably be done with an option to Meteor.loginWith<service>.

e.g.

Meteor.loginWithGoogle({..., loginOtherAccount: false, ...});

[zimme]

I don't want to make Meteor.loginWith<service> work different than Meteor.loginWithPassword by default.

[brettle]

Instead of requiring that client code be changed to handle the typical case of not switching users, how about having the server code assume that the user was trying to add a service instead of switch users, and throw a "logout to switch" error to abort the login? To handle the case when a user actually does want to switch, we could add Meteor.switchUserWith<service> methods or pass a loginOtherAccount: true option to Meteor.loginWith<service>, but it would usually be just as easy to have the client code call Meteor.logout and then Meteor.loginWith<service> without any options.

FWIW, the brettle:accounts-logout-to-switch package takes the above approach.

[zimme]

Solid ideas, feels like if we throw logout-to-switch the "ui" package could just Meteor.logout and Meteor.login` and we don't have to over ride more functionality.

[splendido]

Please consider that changing behaviour of client-side calls using different parameters is not safe, since a malicious user could always make the same call withuot the correct parameters for the current context.

[brettle]

@zimme, that was exactly my thinking.

@splendido, in all the proposals we've been discussing, security is still enforced on the server. Extra client-side parameters and methods are only used to communicate user intent.

[splendido]

@brettle I was referring to the above proposal from @zimme

Meteor.loginWithGoogle({..., loginOtherAccount: false, ...});

which is more than fine in this case since the request would be to link another account to the currently logged in user which, in case, would be the user's intended behaviour.

Other cases could put it the unsafe way.
Just wanted to highlight that changes in the current flows should probably be done on the server side and hence, probably by changing the current Accounts logics, unless we can find some hooks configuration to achieve what we need.