Posted by killes@www.drop.org on August 22, 2009 at 6:18pm
7 followers
| Project: | Bakery Single Sign-On System |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | drupal.org redesign |
Issue Summary
This is requested for the redesign.
I am not sure what the requirements exactly are, though.
Sharing user pics seems obvious.
Comments
#1
I've added support for shared images. This makes a few assumptions, ie that http://domain.com/files/... is the same as http://sub.domain.com/files...
Tweaking could be done in the preprocess function.
#2
Just a word of clarification:
the image path of the master site does /not/ have to be the same as on the slaves (if it was, image sharing would work out of the box). However, the master site's image path must be accessible under the slave site's doc root.
Currently, users can also upload different images on slave sites. These get clobbered once you update the image on the master, though. Not sure this is bug or feature.
#3
Currently the following fields can be shared:
mail, name: mandatory
optional: language, picture, signature, timezone. The slave sites have the option to ignore data sent by the master. Everything admin-configurable.
We need to discuss how profile data will be stored in the future.
#4
user status is a field that will be available for sharing soon.
#5
Any news on this? Current version provides checkboxes for user-defined profile fields however values don't cross over.
#6
Problem is in the following segment:
Line 95:// We store email/name if they changed. We want to wait with doing
// anything else until the changes are saved locally.
foreach (variable_get('bakery_supported_fields', array('mail' => 'mail', 'name' => 'name')) as $type => $enabled) {
if ($enabled && isset($array[$type]) && $account->$type != $array[$type]) { //CONDITIONS ARE NOT MET
$_SESSION['bakery'][$type] = $array[$type]; //AND THIS VALUE IS BLANK
}
}
To fix it removed of the conditional and loaded the user/profile information...
// We store email/name if they changed. We want to wait with doing// anything else until the changes are saved locally.
global $user;
profile_load_profile($user);
foreach (variable_get('bakery_supported_fields', array('mail' => 'mail', 'name' => 'name')) as $type => $enabled) {
$_SESSION['bakery'][$type] = $user->$type;
}
#7
- applied patch #6 (currently at line 102)
- as user 1, entered user account edit on master node
- changed the user picture, on save:
fatal error: Call to undefined function profile_load_profile() in /var/www/drupal/sites/all/modules/bakery/bakery.module on line 105that happens even if the User Picture field is not ckecked as a "supported profile field" in Bakery configuration.
Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.4 with Suhosin-Patch (so far SSO seems to work)
Content Profile module
Ubuntu 9.04
#8
If I may, I'd like to propose a hook-based general solution to sharing data with Bakery. The master side would invoke implementation of its own hook for defining what data to share and slaves would do similar to respond to incoming data. Modules that need to sync their own data could implement these hooks. Thoughts?
#9
Proposal, two hooks, one for transmitting data and the other for receiving and acting upon.
Update on master:
1)
bakery_user_presave()invokes 'bakery_transmit_fields' hooks (or whatever, I don't care about the hook name) passing the $account object2) A module implements the hook, returning an array of unique keys with the updated values
3)
bakery_user_presave()fills$_SESSION['bakery']3)
bakery_user_update()is left the same as it is, populating the payload, mixing, and signing4) slave receives POST and in
bakery_eat_stroopwafel_cookie()invokes 'bakery_receive_fields' passing it the array of fields5) a module on slave implementing the receive hook takes the array of keys and values and for its keys does its own update
Thoughts:
- Ideally, the transmit hooks should only pass back fields that have actually changed on the master
- This methods relies, obviously, on sharing data only through updating the user account (user_save)
#10
Here's a patch implementing the proposal in #9. One big change is rather than just dumping $cookie['data'] into $_SESSION['stroopwafel'] at the top level I leave it within 'data' to protect against any hook implementations overriding certain elements.
I may follow up with a patch or test module implementing role sharing #[547524]
Edit: This is for Drupal 7. I'll implement in Drupal 6 later.
#11
Updated patch sends $edit and $category to transmit hooks.
Also for D6.
#12
There is some test code in http://drupal.org/node/547524#comment-2913504 for sharing roles that you can see how the hooks work.
#13
Bakery could implement these hooks on behalf of the user and profile modules, which would replace the existing sync implementation.
There are two UI aspects that would need to be handled.
1) Choosing which fields are synced. Right now Bakery puts options on the admin screen. There could be a new hook that provides available sync fields. How would the transmit hook have to change if only some of the available fields were set to be synced?
2) The master sees a message from the slave regarding updating. Should receive hooks return a message and pass/fail?
#14
To incorporate #704488: Update rollback functionality handling for sync hooks I think we need to alter the communication between slave and master. The response HTTP status is good for overall pass/fail, but what if a particular update fails? Rather than rolling back all updates if the slaves response HTTP response is 409 the body should contain pass/fails the master could parse it and record the particular fails. The slave response could be JSON.
Another, simpler idea would be to just use the existing response code (messages) and have the master just record that an update resulted in a 409 and the slave would handle rolling a particular update back. Perhaps rollback is a flag on the receive hook?
#15
Here's new sync hooks including rollback functionality and altered reporting (using latter method mentioned in #14).
I think receive hooks should implement rolling back themselves, rather than the eat stroopwafel function invoking them again, or another hook. I'll demo this in #547524: Role sharing
#16
tag
#17
Note, the patch in #15 doesn't handle sync during account creation on the slave. It only handles updates.
Examiner.com needed sync during account creation and I went with a method using XMLRPC. I could provide that here but I think we need to first address what the best method of communication between master and slave is. RPC, REST, something else?
#18
We're going with POST. The patch here will need to be updated for the new gingerbread cookie #821436: Request account information from master
#19
hi what is the hooks of data function,
2ndly how i call a function of class no1 into class no2,using php
#20
I've applied patch in #15 to 6.x-1.x-dev, but not quite got it working yet.
What is the purpose of the $edit var at line 103? I get a PHP notice because it's not initialized.
#21
Sorry, I worked it out, ignore last comment. It's supposed to refer to parameter 2 of hook_user, which is usually called edit, but for some reason is called $array here.
#22
I was hoping Drupal.org could standardize sharing using public JSON APIs, like https://association.drupal.org/api, but I've changed my mind.
I think the approach here is good, but will need to be updated to be in line with the current code. DrupalCon Munich is looking to use this right away.
#23
I filed #556666: Sync hooks: Enable sharing of arbitrary data for Drupal.org's future implementation of this hook. That code could make its way into a generic bakery add-on if it does well, but I think shortcuts are likely, since Munich wants to use this a few months ago.
#24
#23 I think you mean to link to #1597500: Implement bakery hooks to save user information for d.o implementation. There I mention my preference for a sync-less Bakery 3.x branch that provides these hooks.