osimons wrote:
>
> On Nov 15, 10:57 am, Christian Boos <[EMAIL PROTECTED]> wrote:
>
>> Alec Thomas wrote:
>>
>>> On 11/14/07, Christian Boos <[EMAIL PROTECTED]> wrote:
>>>
>>>> Alec Thomas wrote:
>>>>
>>>>> ...
>>>>> 2. Add an interface that allows plugins to declare which permissions are
>>>>> valid for attachments in their realm. The LegacyPermissionPolicy
>>>>> could then do the job of remapping permissions.
>>>>>
>>> I contend that option 2 is almost worse than option 1 in that
>>> respect: it forces plugin authors to add even more legacy permissions,
>>> whereas option 1 does not. It's also possible that option 1 would be
>>> 100% forward compatible.
>>>
>>> Still, either would work. Anybody else got some thoughts
>>>
>> -- Christian
>>
>
> I've just implemented attachment support for my FullBlog plugin, and
> chatted with Alec on IRC as a precursor to this RFC. My experience is
> basically:
>
> 1) Adore the flexibility of using a permission policy to implement the
> support for attachment permissions. For instance I actually have 2
> modify permissions in my blog plugin (BLOG_MODIFY_OWN,
> BLOG_MODIFY_ALL) where the lower level permission would only allow you
> to add and delete attachments if it is your own blog posts - not on
> blog posts where you aren't author. Mapping to legacy permissions -
> implicitly or explicitly - would be step in the wrong direction. And
> certainly having them re-appear in trac-admin or web admin when they
> have been gone for years does not feel right.
>
> 2) My main qualm about the permission policy was of course having to
> add it to trac.ini when it really just extends the a built-in module.
> For this I see two alternatives:
>
> a) Make security policies default enabled, but if it isn't specified
> in the permission_policy list it will just be checked at random/load
> order after the explicityly declared policies. The order can be
> resolved by primarily using the trac.ini list, then default trac
> policies (if not in specified list), and lastly unspecified policies.
> To disable a policy one uses the [components] section like for any
> other plugin - it seems to me uncessary to enable the policy both in
> components and include it in permission_policies.
>
> b) Make an attachment extension point for the attachment permission
> policy that queries the implementor for a resource (attachment) realm
> what permission to ask for in each circumstance - forwarding the basic
> action (ATTACHMENT_VIEW etc.), username and the parent resource. In my
> case above I can then return .._OWN or .._ALL depending on what
> resource it is. Then only default policies are in use - with some
> help.
>
>
Ok, thanks for the clarifications. I also think that adding additional
attachment permissions in the default "coarse-grained" permission store
was not a step in the right direction...
So what about something like that:
class ILegacyAttachmentPolicyDelegate(Interface):
def check_attachment_permission(action, username, resource, perm):
"""Return the usual True/False/None security policy decision
appropriate for
the requested action.
:param action: one of ATTACHEMENT_VIEW, ATTACHMENT_CREATE,
ATTACHMENT_DELETE
:param username: the user string
:param resource: the `Resource` for the attachment. Note
that when
ATTACHMENT_CREATE is checked, the
resource `.id`
will be `None`.
:param perm: the permission cache for that username and resource
"""
class FullBlog(Component):
# ILegacyAttachmentPolicyDelegate methods
def has_attachment_permission(action, username, resource, perm):
if resource.parent.realm == 'blog':
if self.get_blog_post(resource.parent).author == username:
return 'BLOG_MODIFY_OWN' in perm
else:
return 'BLOG_MODIFY_ALL' in perm
-- Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
