[filearts]

This is a very nice solution and API for the front-end. It took me a couple part-time months to put together a similar (not modularized) solution for a rewrite of Plunker. There is quite a bit of juggling of information to do to pass around the appropriate information between client, server and auth providers that seems to have been nicely abstracted.

There were three major challenges for me in my implementation and I'm wondering how these could be addressed with Satellizer:

1. Anonymous content creation that can be attributed to a user upon sign-up or sign-in. On Plunker, anonymous users can create 'plunks' that will then attributed to them if they decide to register. This is important to allow streamlined user acquisition.

2. Account merging when someone accidentally creates two different user accounts with different social identities. This gets weird when anonymous content creation is involved since someone could create content while signed out and would need all that content re-attributed when they sign in.

3. Multi-provider authentication. In Plunker, certain features will only be available if the user has linked (for example) Dropbox. This means consumers of the api need to be able to add / remove social identities to / from users.

Hope to hear how you might attack these problems with something like Satellizer (or other people's approaches that have worked).

[ovidiup]

The account merging part is something your server should handle.

In my app I maintain a users table that has columns (google_account_id, facebook_account_id, twitter_account_id, etc), pointing to individual rows in a separate accounts tables (e.g. google_accounts, facebook_accounts, twitter_accounts etc). When a user adds an existing account_id, I take care of merging the two different users rows, populating appropriately the account_id in one of the rows, then deleting the extraneous users row. I also migrate the existing data referring to the to-be-deleted user row to the one I plan on keeping.

[filearts]

Thanks for the reply. That is the approach I take. Users have one or more identities which seems to be the logical way of handling this regardless of the physical structure used to store the association.

While you gloss over it a bit, the 'migrate the existing data' part is a challenge of its own because it means that suddenly the auth component needs to either know every place where a user<->content association is made or you need some sort of queue set up to publish user merges to all parts of the app in a reliable and durable way so that they can process the migration themselves.

I would say that this is also a UI concern and therefore something that a service like this would need to handle because it should _not happen automatically_. When a user conflict is detected, the user should be able to make a decision via appropriate UI. We would not want two accounts being merged simply because of some degenerate case where someone logged into their account on a borrowed computer.

[jgrowl]

You could create an identities table which consists of a provider and a uid where Users have many identities. Something similar to this:

https://github.com/intridea/omniauth/wiki/Managing-Multiple-...

Use what works for you obviously, but this would have the benefit of scaling easier if you end up ever needing to support additional providers.