Wiki Acl
inyoka.wiki.acl
This module handles security levels for the wiki. The system uses the wiki storage to store the patterns. Whenever the data is loaded from the wiki pages that hold access control information the storage module splits the data already into easy processable data.
This is an important detail because the ACL module knows nothing about the names of the privileges on the frontend. Internally the names of the privileges are mapped to integer flags.
All privilege functions consume either the privilege flags or the internal short name of the privilege. The shortnames are specified in the privilege_map dict and different from the user interface which uses translated versions of the variables.
Because metadata is part of a page the views have to check if the metadata changed in a way the user is not allowed to change it. This module provides a function called test_changes_allowed that checks for that.
- copyright:
2007-2024 by the Inyoka Team, see AUTHORS for more details.
- license:
BSD, see LICENSE for more details.
- inyoka.wiki.acl.GROUP_OWNER = 'owner'
because we use different names in the german frontend these constants hold the name used in the frontend. i call bullshit, we use english names again and the constants are left as an exercise for the reader.
- class inyoka.wiki.acl.GroupContainer(user, page_name)
This class fetches the groups for an user in a lazy way. This is used by the get_privilege_flags to not load groups if they are not used for a specific query.
Use it with the in-Operator:
>>> user = User.objects.get_anonymous_user() >>> groups = GroupContainer(user, 'Main_Page') >>> 'All' in groups False >>> 'something' in groups False
- load()
Load the data from the database.
- inyoka.wiki.acl.LENIENT_METADATA_KEYS = frozenset({'X-Attach', 'X-Link', 'X-Redirect'})
metadata users without the PRIV_MANAGE privilege can edit.
- class inyoka.wiki.acl.MultiPrivilegeTest(user)
Efficient way for multiple privilege tests for one users to many pages.
- get_groups(page_name)
- get_privilege_flags(page_name)
- get_privileges(page_name)
- has_privilege(page_name, privilege)
- inyoka.wiki.acl.PRIV_NONE = 0
keep this updated when adding privileges
- inyoka.wiki.acl.PRIV_READ = 1
the internal privilege representations. because we try to keep the interface as fast as possible the privilegs are bit fields and not python sets.
- class inyoka.wiki.acl.PrivilegeTest(user, page_name)
An instance of this class is passed to all the action templates. Attribute access can then be used to check if the current user has a privilege the current page.
- jinja_allowed_attributes = ['read', 'edit', 'create', 'attach', 'delete', 'manage']
- inyoka.wiki.acl.get_privilege_flags(user, page_name, groups=None)
Return an integer with the privilege flags for a user for the given page name. Like any other page name depending function the page name must be in a normalized state.
- Parameters:
groups – used internally by the MultiPrivilegeTest
- inyoka.wiki.acl.get_privileges(user, page_name, groups=None)
Get a dict with the privileges a user has for a page (or doesn’t). user must be a user object or None in which case the privileges for an anonymous user are returned.
- Parameters:
groups – used internally by the MultiPrivilegeTest
- inyoka.wiki.acl.has_privilege(user, page_name, privilege, groups=None)
Check if a user has a special privilege on a page. If you want to check for multiple privileges (for example if you want to display what a user can do or not do) you should use get_privileges which is faster for multiple checks and also returns it automatically as a dict.
- Parameters:
groups – used internally by the MultiPrivilegeTest
- inyoka.wiki.acl.privilege_map = {'attach': 8, 'create': 4, 'delete': 16, 'edit': 2, 'manage': 32, 'read': 1}
used by the decorator
- inyoka.wiki.acl.require_privilege(privilege)
Helper action decorator that checks if the currently logged in user does have the privilege required to perform that action.
- inyoka.wiki.acl.test_changes_allowed(user, page_name, old_text, new_text)
This method returns True if the user is allowed to change the text of a page from old_text to new_text. At the moment this just checks for changed metadata, in the future however it makes sense to also check for banned words here.