Hi Rob, > > My analysis is that the Anonymous user doesn't have the 'Copy or Move' > > permission on portal_membership- how can I change this? > > this is almost certainly wrong. the 'Copy or Move' permission needs to be > available on the member object, which lives in portal_memberdata. your > permissions on portal_membership are unrelated.
Ok, that makes sense- I was probably confusing the parent object with the object in question when tracing through the permissions checks. > > I've already given the Anonymous user the following permissions: > > Add portal member > > Copy or Move > > membrane: Edit member id > > membrane: Register member > > remember: Add FolderishMember > > this opens up what is colloquially known as a BASH... i.e. a Big Ass Security > Hole. i'm pretty sure you've just made it possible for any anonymous visitor > to your site to change the actual id of any of your member objects. that > means that i don't even have to be logged in to change your username from > 'michael' to 'pwn3d'. > > it's very dangerous to go around granting permissions to Anonymous unless you > really understand what you're doing. Understood- these change were only made to my development instance in the interests of uncovering the required permission. It would not be an acceptable solution for me to deploy the product with these important rights being assigned to Anonymous. <snip> > my guess is that all of the places where you've tried to hook in the custom > setting of the 'id' value are being hit AFTER this state change has already > happened. if this is indeed the case, then your options are a) hook the id > mangling code up so that it's triggered before the state change is triggered > or b) rewrite the id mangling code so that it uses a different mechanism to > change the id which won't engage Zope's usual security checks, or c) rewrite > the id mangling code so that it escalates the privileges of the user to beyond > that of Anonymous, changes the id, and then immediately returns the user to > his unprivileged state. Thanks for the detailed insight into the remember workflow setup, adding a before_script in the workflow to update the id seems like the cleanest approach. > > I've had another idea around trying to implement this id change in the > > approval workflow, anyone have some general approach tips? > > this is a fine approach. workflows can trigger "before transition" scripts; > you'd want to hook your code in so that it's fired before the automatic > transition that removes the edit privileges from the user. My workflow is just a simple one-step approval one, based on the member_approval_workflow in remember. thanks again for the prompt response. michael -- Archive: http://www.openplans.org/projects/remember/lists/remember/archive/2008/06/1213170723719 To unsubscribe send an email with subject unsubscribe to [EMAIL PROTECTED] Please contact [EMAIL PROTECTED] for questions.
