Description
I am not at all sure if this is a bug or if I misunderstood the ACL syntax.
I think you maybe have rather misunderstood it.
- Ok, thanks for the fast response. Seems I need to read the documentation again.
As far as I understand, when looking if user name can do action dowhat, the idea of AccessControlList.may(name,dowhat) is to search all ACL lines relevant for name and return the boolean value of dowhat for the first line that has dowhat.
No. You will get the first entry relevant for name - except when you have entries with +/- (they do not stop processing). If the entry has no +/-, processing will stop there. And if the right is not mentioned, it defaults to false.
Assume the following situation:
config.acl_rights_before does not mention dowhat
config.acl_rights_default does not mention dowhat
- The checked page does not have ACL
config.acl_rights_after allows dowhat for name
I would expect that the result should be True, because dowhat is only contained in the last ACL line at all. No.
Instead, the result was False and the reason was that some earlier ACL line (e.g. one containing All mysteriously contained dowhat with value 0. That is no mysterium, that is intention.
Example
I was trying to implement some new rights called 'approve_x', 'approve_idc', 'approve_ddic' for some specific MoinMoin enhancements. In my simple case, these do not even have to be set on the page level, it is only a user rights issue.
Thus, I used the following configuration:
1 acl_enabled=1
2 acl_rights_before='RobertSeeger:read,write,admin,delete,revert,massdelete'
3 acl_rights_default='+Known:admin,read,write,delete,revert'
4 acl_rights_valid= ['read', 'write', 'delete', 'revert', 'admin','approve_x', 'approve_idc', 'approve_ddic']
5 acl_rights_after='+All:read +RobertSeeger:approve_x,approve_idc,approve_ddic'
You rather maybe want:
1 acl_enabled=1
2 acl_rights_valid= ['read', 'write', 'delete', 'revert', 'admin','approve_x', 'approve_idc', 'approve_ddic']
3 acl_rights_before='RobertSeeger:read,write,admin,delete,revert,massdelete,approve_x,approve_idc,approve_ddic'
4 acl_rights_default='Known:read,write,delete,revert'
5 acl_rights_after='All:read'
and a enhanced SecurityPolicy with a little debug print:
1 class SecurityPolicy(Permissions):
2 def do(self,action, pagename, **kw):
3 """ Check whether user may do "action" with this page.
4
5 `kw` allows passing more information without breaking user
6 policies and is not used currently.
7 """
8 page_acl=self.getACL(pagename)
9 allowed=page_acl.may(self.user.name, action)
10 print "<P><HR>ACL for %s at %s:\n<br>%s\ncheck do %s=%s\n<HR><P>" %(self.user.name,pagename,str(page_acl.acl),action,allowed)
11
12 return allowed
Do not use print any more. NEVER. Use request.write("string").
- I understand that. I thought, however, that in this situation I have no access to request (I found out later that there is user._request) and print still works for debugging purposes (even in places where request.write throws a stdout guard error). I do no longer use it in any "permanent" output functions.
Details
MoinMoin Version |
1.1. |
Python Version |
Python 2.3.3 |
Discussion
RobertSeeger deleted this part after understanding his misconception.
By the way it would be nice if my function
could go into the standard SecurityPolicy class or (even better) some of you gurus could make this class automatically provide named functions for all items in config.acl_rights_valid. This would allow for people that are less ruthless than myself (I do frequently have to mess around with the core MoinMoin code) to configure new rights and use them in extensions (actions, macros, processors).
We will look into that.
Plan
- Priority:
Assigned to: ThomasWaldmann (or GustavoNiemeyer if he wants)
- Will be fixed in release: No Bug. Maybe other suggested changes in 1.3.