Feature suggestion: Checking permissions, rather than users/groups

[iainhallam]

I've been looking for a plugin to show/hide content based on authorisation, not just authentication, and it looks as though combining this into the ifauthex plugin might be one way to go. Essentially, I'd like to see a syntax to check whether a user has any particular permissions on a target. Examples, in a made up syntax:

<ifauth >AUTH_READ> # satisfied if the current user has a permission greater than read for the current page
<ifauth @mygroup<=AUTH_EDIT?ns> # satisfied if mygroup has less than or equal to edit permission in namespace ns
<ifuath myuser=AUTH_CREATE?.:relative:page> # satisfied if myuser has exactly create permission on .:relative:page

User/group would default to the current user if not given, and target would default to the current page if not given. These specifications could combined with the existing user/group rules to allow fine-grained showing/hiding of content based on both who they are and whether they have permission.

Being able to check the permissions on a page/namespace other than the current one would be useful to be able to show a form to create a page based on whether the user could complete the action, for instance.

[5p4k]

So ACL in Dokuwiki have a "level" configuration, so it would be possible to test the authorization against a certain level. However there are some points that are unclear, to me:

1. What is the purpose of testing a user or group, rather than testing the ACL of the currently viewing user? The page would be static and only depend on ACL values, unless the user happens to match the test condition.
2. It remains the fact that showing and hiding content does not really prevent them from seeing it or modifying it, since the minimum meaningful test is whether they have edit right. That might be confusing, since ifauthex does not really provide any security, just pretty pages.
3. For a fine-grained control, wouldn't be better for the admin to define corresponding groups and assign the users to those groups? at that point the result (for the current namespace) could be achieved using existing functionality.

[listerr]

This might be useful in a situation where there are a lot of groups that give access to the same pages.

Currently, you have to build logic like:

<ifauth @group1 || @group2 || @subscribers || @editors || @admins>
Display content / link here...
</ifauth>
<ifauth !@group1 || !@group2 || !@subscribers || !@editors || !@admins>
No access message... 
If you have a login, please login here...
If you do not have a login,  please register as a new user: <link to registration page>
</ifauth>

If you've used ifauthex in quite a few places, and now want to add or rename a group, or change what the group can access, you have to update every page where ifauth is in use to make sure the ifauth groups are correct.

If it could check if "current user has read access to a target page", this would become something like:

<ifauth AUTH_READ?:private:page>
Display content / link here...
</ifauth>

<ifauth !AUTH_READ?:private:page>
No access message... 
If you have a login, please login here...
If you do not have a login,  please register as a new user: <link to registration page>
</ifauth>

A bit simpler.

The only slight downside is that it might become complex to understand why (or why not) a user sees particular ifauth output if there are a lot of groups. You are going to have to look in User Manager to see which groups the user belongs to, and then look in ACL manager for the page to understand why it's showing content (or not). That's not something a regular user can do, only superusers. A regular user can contact the admin to say "Fred can't see this. Can you add fred to group X?" but harder to say "I want only for people with access to this page. Fred can't see it, but I don't know why, or what groups he should be in."

Other possible solutions:

1. "Groups of groups" e.g. a config option to define "virtual" groups, which contain a list of groups

<ifauth @@VIRTUAL_GROUP>
...
</ifauth>

2. The hack for that might be to create a "dummy user" which is a member of all the wanted groups, then you can just do:

<ifauth +subscriber>
  Visible only to groups which user "subscriber" belongs to.
</ifauth>

Then if you want to update the list of groups, it only has to be done in one place.

3. Some wildcard match on groups so if you name them consistently, you can just match:

<ifauth @group_*>
...
</ifauth>

Then it would match "group_foo, group_bar, group_baz" etc.

[5p4k]

Ok I understand the purpose now. In fact, in this specific case, it could even benefit from a <elseauth> and <elseifauth ...> option (which I was considering).

[iainhallam]

So ACL in Dokuwiki have a "level" configuration, so it would be possible to test the authorization against a certain level. However there are some points that are unclear, to me:

1. What is the purpose of testing a user or group, rather than testing the ACL of the currently viewing user? The page would be static and only depend on ACL values, unless the user happens to match the test condition.
2. It remains the fact that showing and hiding content does not really prevent them from seeing it or modifying it, since the minimum meaningful test is whether they have edit right. That might be confusing, since ifauthex does not really provide any security, just pretty pages.
3. For a fine-grained control, wouldn't be better for the admin to define corresponding groups and assign the users to those groups? at that point the result (for the current namespace) could be achieved using existing functionality.

In my case, I want to have a page that shows Struct plugin data, and allows creating new pages with that data on. More concretely, imagine I have a namespace :events:, with pages underneath having a Struct schema applied so that they all have title, start_time, and end_time set. The Bureaucracy form to create new events shouldn't be under that namespace, so would probably just be on the page :events.

The :events page could list all the events in the next week, and show anyone who has the permission AUTH_CREATE in the :events: namespace a form for making a new event. If I used ifauthex to check this, checking the current page wouldn't be enough to tell me whether someone could successfully create a new event page, as it needs to check the permissions of :events: (namespace), not the current (:events) page. If they don't have permission, I could use an <elseauth> or the opposite <ifauth> to show a message.

I could just show the form, and if they didn't have permission, they'd get an error, but that doesn't feel like good UI, so I was looking for something that could show and hide parts of the page based on permissions elsewhere in the site.