Multi-Site support
Opened this issue · 3 comments
As it stands now you cannot have a resource with the same id linked to multiple users. This causes an issue if you have a multi-site setup and a user has distinct accounts across multiple sites (in this example case each site is distinct and users are not shared across sites).
Adding an optional siteaccess field to OAuthEz and the ability to lookup in the repository by ResourceUserId and siteaccess should allow this.
I see also that the security user is looked up by email. Maybe that rules out the ability to have multiple users with the same email address?
What do you think?
Hi @wizhippo !
First of all, yes, we can't change the fact that multiple users cannot have same email address. I'm not sure it is a good idea to change/override that. But loading users by email is a feature that does not work in this version anyhow as it was meant to allow connecting with existing eZ users, but was not finished on time for release.
Your proposition could work, but not by relating the social link to one specific siteaccess (what if some of the sites in multi-site setup use more than one siteaccess or more than one siteaccess group?), but by assigning a user group per siteaccess/siteaccess group where all social login accounts would be created and from where would users be loaded when logging in. The config for user group is already there (although separated by resource owner, this could be improved to provide a fallback group), and users are already created in specified user group (I think), we would only need to check if user is really in specified user group when logging in.
That way, you could have one Facebook user linked to two eZ users in two user groups (one for site1, one for site2), and user in correct user group, per configuration in the bundle, will be loaded.
What do you think?
Ping @iherak @alymdrictels
Thanks @emodric
I had been looking at the siteaccess in a too simplistic way as in my current venture with multi-site every site has it's own siteaccess definition. The user group sounds like a much better and flexible solution.
Hi @wizhippo
Implementing a solution to this will take a hefty chunk of time, but I plan to look into it over the next few weeks.