[dokuwiki] Re: Proposal for an AUTH_USERDATA_CHANGE event

  • From: "Gabriel Birke" <Gabriel.Birke@xxxxxxxxx>
  • To: <dokuwiki@xxxxxxxxxxxxx>
  • Date: Wed, 13 Aug 2008 17:25:14 +0200

Hello,

attached to this mail you find a patch for inc/auth/plain.class.php to
support the new event.
Also an action plugin example that will log the changes to an XML file.

Greetings,

Gabriel

> -----Original Message-----
> From: dokuwiki-bounce@xxxxxxxxxxxxx 
> [mailto:dokuwiki-bounce@xxxxxxxxxxxxx] On Behalf Of Gabriel Birke
> Sent: Wednesday, August 13, 2008 1:32 PM
> To: dokuwiki@xxxxxxxxxxxxx
> Subject: [dokuwiki] Proposal for an AUTH_USERDATA_CHANGE event
> 
> Hello,
> 
> recently, a requirement for our Wiki was to log all changes 
> to the user
> data: New users registering, changes in usernames and groups, and the
> deletion of users. 
> 
> The "quick and dirty" solution was to add a logging routine 
> to our auth
> class (plain) and call the routine from the createUser, modifyUser and
> deleteUser routines. Now I would like to propose an 
> extendable solution that
> has more use cases than just logging and will survive an 
> update of the core
> code.
> 
> Instead of calling a method, the new AUTH_USERDATA_CHANGE event is
> triggered. The event gets the action (create, modify, 
> delete), the "old" and
> the "new" user data as event data. And an action plugin could do the
> logging. I can imagine other uses and plugins for this new event:
> 
> - remove users from acl.auth.php when a user is deleted
> - prevent changes to users if certain criteria (IP address, user name,
> password strength) aren't met
> - monitor patterns in changes (for statistics or security)
> 
> I would like to hear feedback for this proposal. 
> 
> There is one architectural hurdle to this: Since each auth 
> class overrides
> the createUser, modifyUser and deleteUser method, the code 
> for triggering
> the event must be put in each auth class. Maybe someone can 
> assist me with
> the pgsql, punbb and ldap classes, since I have no test 
> systems for these
> auth methods at the moment. 
> An alternative to this would be changing the auth class system from
> inheritance to composition: The current auth class API 
> remains, but there is
> one auth class that dispatches the api call to various auth 
> adapters. While
> I am certainly able to do such a change, I won't do it 
> without having the OK
> from the community.
> 
> Greetings,
> 
> Gabriel
> 
> -- 
> DokuWiki mailing list - more info at
> http://wiki.splitbrain.org/wiki:mailinglist
> 

Other related posts: