That looks exactly like the way Sling is supposed to work. What makes me puzzled is I cant find anywhere in the standard Sling code base that binds to the the sudo parameter, or the sling.sudo cookie although both are defined. Perfectly possible I am not looking hard enough.
Ian On 28 February 2012 11:29, Nate Angell <[email protected]> wrote: > To sudo, you authenticate as the "root" admin user and navigate to > something of the form as folows to sudo as, in this case, the user > "xolotl". > > http://localhost:8080/?sudo=xolotl > > Which sets a cookie named "sling.sudo" > > Name: sling.sudo > Content: "\"xolotl\"" > Domain: localhost > Path: / > Send For: Any kind of connection > Accessible to Script: Yes > Created: Monday, February 27, 2012 4:25:04 PM > Expires: When I quit my browser > > I originally discovered this method in some Sling documentation that > for some reason I'm now unable to find ;) > > = nate > > On Mon, Feb 27, 2012 at 2:04 PM, Ian Boston <[email protected]> wrote: >> On 28 February 2012 05:27, Nate Angell <[email protected]> wrote: >>> Thanks for helping think this through Ian...I certainly wouldn't >>> presume to tell you how the system you wrote behaves ;) >> >> hey, no problem. You must tell me how it behaves, most of the time it >> misbehaves :) >> >>> >>> My experiments show that when one impersonates a user, and then >>> creates a Sakai OAE doc while impersonating, the following values >>> associated with that document are aligned with the user being >>> impersonated (in this example the admin user was impersonating the >>> xolotl user): >>> >>> { >>> "_created": 1330366895100, >>> "_createdBy": "admin", >>> "_id": "4YnjwGFvEeGYOZaTCgABEA+", >>> "_lastModified": 1330366896495, >>> "_lastModifiedBy": "xolotl", >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> That proves it works ! >> >> Out of interest, how are you performing the sudo and what cookies do >> you see in the client once you have sudoed ? >> >> Ian
