-
2013-10-01
skl
I wrote an auth plugins, which "chains" two different authentication methods (auth plugins) based on the username (via a regular expression). As the child plugins can have different capabilities, it would be useful to be able to express these capabilities (which therefore are dependent on the user name) to (e.g.) the user manager. I suggest the extension of the canDo method parameter list by one optional parameter $username, which defaults to null. The existing auth plugins would not be affected, even the existing user manager would work as before, if fed with an auth plugin which uses the extended API.
As far as I can see, only one method of the core would have to be patched: "actionOK" in file "inc/confutils.php", to (en/dis)able specific actions based on the logged in user, e.g. changing the email address or password. Just extend the calls to $auth->canDo() by $_SERVER['REMOTE_USER'], where appropiate.
The aforementioned auth plugin and a patched user manager could then be made available by me.
-
2013-10-10
andi
I'm not sure I understand why this is necessary. Can't you override the canDo() method in your auth plugin and implement the appropriate check yourself?
-
2013-10-10
skl
Sure, I can check using the currently logged in user. But the usermanager plugin needs to be able to check the capabalities of the auth plugin of another user. E.g. the admin is using local plainauth and wants to edit the displayname of an ldap user, which isn't possible.
Also, it says in the auth plugin parent: DO NOT OVERRIDE, so if I adhere to that, I can only fill the canDo array, which is not sufficient.
The mentioned patch in "actionOK" is not necessary, that's right, as the calls are related to the currently logged in user. My canDo() method now defaults to that one.
But the usermanager has to be patched for this specific situation. As there is also involved a new authn/authz split plugin, I'm not yet certain if this can be done in a way that's suitable for every case, or if I have to fork the usermanager plugin. Similar to the existing split plugin written by Pieter Hollants, existing ldap users can "self-register", but additionally, this "self-registering" can be forbidden by config, and the animal admin can add existing ldap users to his wiki manually, using the username or the email address.
The priority may be lowered, as further investigation is needed.
-
2013-10-10
andi
DO NOT OVERRIDE = DO NOT OVERRIDE (unless you know what you are doing) ;-)
-
2014-05-10
Klap-in
Does andi's suggestion solve your question?
-
2014-05-12
skl
Our development is delayed due to further problems concerning the naming scheme of dokuwiki pages/media files.
-
2015-05-15
Klap-in
Is this still required? At the moment my impression is that it is not required..
Therefore I will close this bug for now, if it appears that you require it, please create an pull request at Github. That way we can also provide faster specific feedback to your proposal :)
-
2015-07-07
Klap-in
Relevant function seems already overridable by plugins.