Posted by glennpratt on November 14, 2011 at 3:00pm
5 followers
| Project: | Bakery Single Sign-On System |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
To manage shared data across sites, UUID can save a lot of headache. After dealing with Bakery for a while, I feel some parts of Bakery would be much more straightforward if we had UUID.
Would a patch that introduced UUID to Bakery be acceptable? Could UUID be a dependency or just optional?
Comments
#1
I would prefer to separate Bakery SSO from account data synchronization in future versions, to simplify the module.
#2
So, I tend to agree, but the reason I'm proposing UUID is to negate the need for storage in Bakery (or data sync). In my mind, the only thing I would require from Bakery is UUID (I don't even care about syncing the user name).
#3
You want a UUID to identify the user or for what purpose?
I'm having a hard time following what you mean so maybe making the dependency on UUID and adding a basic example of how it could help as a patch would be worthwhile.
#4
Yes, I want UUID to uniquely identify the user, UID will differ (and requires separate storage per slave, username and email can be changed, so that basically requires bakery to sync fields - though that is nice for d.o, it's something I already take care of elsewhere in my application).
I'll work toward a patch when I can, thanks.
#5
Not sure if this is exactly what was intended by the original issue, but it's certainly a good way to start... As far as I can tell, the attached patch is actually all that's needed to allow Bakery to share UUIDs between sites :)
The use case for this is that if you're using Deploy + UUID to push accounts between sites but also have Bakery enabled, you don't want to wind up in a situation where Bakery creates the account first but winds up giving it a different UUID. Because at that point, the UUID module won't know they're related so you won't be able to sync up any of the additional account data with Deploy.
One could make a good argument that if the UUID module is enabled this should actually be the default behavior... but that's a more complicated patch so for now I'm just making it an option.
#6
Yes, that is what was intended. I'm not using the deploy module, but Services to push accounts around with other related data (often before the user ever shows up for SSO), so I have to funnel it through Bakery first and hand hold it a bit. I'd prefer it just see a user with that UUID already exists and trust me to handle the data.
#7
There's a general goal for bakery to be just about SSO and not about data sharing. If there's a way that UUID and Services or Deploy can handle that, great!
Steps to test this:
1. install a master and slave with bakery and uuid modules
2. register a user on master and then have them visit slave, confirm uuid synch
3. register a user on slave, confirm uuid synch
4. admin creates user on master, pulls to slave, confirm uuid synch
Anything else?
#8
I'd add this to be thorough:
5. Create a user with the same UUID on master and slave (without using Bakery). Confirm SSO works.
#9
Those lists look correct to me. While working on this so far I believe I already tested everything but #4. I just tried #4 quickly now (since I was easily set up to do so) and it seemed to work fine as well.
#10
Testing this with different types of user registration configurations (i.e., email confirmation required, admin approval required, etc) would also be a good idea.
This patch might not work correctly in some of those scenarios. I think I just inadvertently ran across that when testing something else, but didn't have a chance to do a full test.