michaeljoseph wrote:
Hi,
We get the following permissions error when attempting to set the id
of our custom remember.content.member.Member subclass either by using
an event subscriber, abusing the Archetypes validation hooks or
setting _at_rename_after_creation=True and overriding generateNewId:
<---SNIP--->
The action against the <em>ethekwinimember.2008-06-03.1147579855</
em> object could not be carried out. One of the following constraints
caused the problem: <br><br>The object does not support this
operation.<br><br>-- OR --<br><br>The currently logged-in user does
not have the <b>Copy or Move</b> permission respective to the object.
<---SNIP--->
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.
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.
Any ideas?
usually in Plone you have to be logged in before you can create content.
Remember is an unusual case, b/c you HAVE to allow Anonymous users to create
member objects if you want people to be able to join your site. this has to
be handled carefully, however, b/c you DON'T want Anonymous to have any
privileges on member objects after they've been initialized.
Remember achieves this with some fancy workflow footwork. Anonymous has the
'Add portal member' permission, which is the add permission for member
objects. the default workflow state for member objects is 'new'; when a
member object is in this state, Anonymous has the 'Modify portal content'
permission, which means that the Anonymous user can edit the member object,
allowing him to specify email address, fullname, etc.
here's where the magic comes in. when you submit these values, there is an
"automatic" workflow transition that is fired which moves the member object
into the next workflow state (either 'public' or 'pending', usually). this
next workflow state does NOT give Anonymous ANY permissions on the object.
once a member object has been concretely associated w/ a particular person,
then the security becomes much tighter on the object.
the automatic workflow transition is protected by a "here/isValid" guard.
this means that the workflow state change will only happen if the member
object passes validation. this way you don't get locked out of your member
object if, for instance, you forget to enter an email address.
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.
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.
note that i don't know the details of your workflow setup; you'll definitely
need to examine that carefully to make sure the permissions are set correctly
according to your needs. you can learn more about how all of this works here:
http://plone.org/documentation/tutorial/understanding-permissions/
especially:
http://plone.org/documentation/tutorial/understanding-permissions/workflows
good luck,
-r
--
Archive:
http://www.openplans.org/projects/remember/lists/remember/archive/2008/06/1212775415053
To unsubscribe send an email with subject unsubscribe to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.
