jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1005) More Fine grained Permission Flags
Date Thu, 09 Aug 2007 13:09:42 GMT

    [ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518708

Stefan Guggisberg commented on JCR-1005:

first of all thanks  for the patch!

i have the following concerns regarding the patch:

- the permission constants READ, WRITE and REMOVE are bitmask flags,
  i.e. any new constant would need to be a power of 2
- the current flags apply to the target, i.e. WRITE permission on the node to 
  be modified etc. the new constant ADD refers to the parent of the target
  which seems to be inconsistent.
- the patch is incomplete. it doesn't cover all locations that check permissions.
  check for usages of AccessManager.isGranted()
- i am afraid that the proposed change wouldn't be backward compatible
  with existing AccessManager implementations


> More Fine grained Permission Flags
> ----------------------------------
>                 Key: JCR-1005
>                 URL: https://issues.apache.org/jira/browse/JCR-1005
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: security
>    Affects Versions: 1.3
>            Reporter: Claus Köll
>         Attachments: acces.patch
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission
> AccessManager.WRITE will be used. This is a Problem in a  WebDav Scenario with Microsoft-Word
because if i open a Node and 
> try to save it i need write permissions on the parent node. this is ok. If a user trys
to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message