Re: [Phpwiki-talk] Speaking of breaking things. (was Re: xgettext problem (was ...))

[Jeff D. <da...@da...>]

On Thu, 20 Feb 2003 08:34:11 +0100
Reini Urban <ru...@x-...> wrote:

> Please do so. Good stuff.

All righty.  Expect it later today.

> I'm also refactoring my UserAuth stuff, as promised years :) ago.

Ooh. Very good.

I've a couple comments/suggestions, I suspect you might already have
thought of these, but I'd thought I'd toss them out.

1. Each of the authentication methods and means of storing/retrieving
   user information (i.e. prefs, password, etc...) should be encapsulated
   in an object.

   I.e. introduce a new virtual base class called AuthDB.  I, obviously
   haven't thought this out too fully, but something like.

   // Return codes.  Note that you can check for success
   // by casting to int:  if ((int)$db->checkPassword(...))...
   define ('AUTHDB_OK', "1 OK");
   define ('AUTHDB_BADUSER', "0 Bad User");
   define ('AUTHDB_BADPASSWORD', "0 Bad Password");

   // AuthDB doesn't support the requested operation.
   define ('AUTHDB_NOTSUPPORTED', "0 Not Supported");
 
   class AuthDB {

        // Get name of authentication method.
        function getName() { return get_class($this); // or something ? }

	// Returns AUTH_LEVEL, or one of
AUTHDB_{BADUSER,BADPASSWORD,NOTSUPPORTED}
	//
	function checkPassword($userid, $password) { return AUTHDB_NOTSUPPORTED;
}
        function setPassword($userid, $oldpw, $newpw) { return
AUTHDB_NOTSUPPORTED; }

        // ... this part is a little fuzzier as to exact API...
        function createUser($userid, $user_data) { return
AUTHDB_NOTSUPPORTED; }
        function getUserData($userid) { return AUTHDB_NOTSUPPORTED; }
        function updateUserData($userid, $user_ata) { return
AUTHDB_NOTSUPPORTED; }
        // ...
   }

   There would be a subclass of AuthDB for each type of authentication.
   (Including AuthDBAdmin (for authentication vs the admin name and pw
   in index.php) and AuthDBBogo.)


   Then, e.g. to check passwords, instead of giant nested ifs which need
   to be adjusted every time someone wants to add a new authentication
method:

   class WikiUser {
     ...
     function _pwcheck($user, $pw) {
       global $AuthMethods;
       foreach ($AuthMethods as $db) {
            $authlevel = $db->checkPassword($user, $pw);
    	    if ((int)$authlevel)
	        return $authlevel;
       }
       return WIKIAUTH_ANON;
     }
   } 


2. Probably we need to identify and handle two different kinds of prefs.
   There are some which should definitely be storable in a cookie, e.g.
   for anonymous users --- things like date-formatting preference,
   and edit area size, (and default user name).

   Things like password and e-mail are more tightly associated with
   an _authenticated_ user.  These, of course, should not be stored
   in cookies... I think we should start calling them user_data
   instead of prefs.

   Of course, users might want to store prefs as part of their user_data.
   (It's unclear to me which should take precedence if prefs are available
   both from a cookie and from $user_data['prefs']...)

2a.When refactoring make sure that it's easy to drop back to only
   allowing BOGO-authentication.   I had to comment out a lot of
   code (and munge some templates pretty heavily) to get this to work
   and look reasonably clean...

   Many wikis will want to remain (in the wiki tradition) open, with
   no user registration.

2b.Please make it easy to disable the auto-generation of all the fancy
   user sub-pages.  I can see where some might like them, but to me
   they seem very non-wiki-ish...
   

Whew... that's a load off my chest.  Sorry ... I didn't mean to
unload on you like that.  :-)


Jeff

PS: Is the current user authentication code working at all?  I notice
  there's   been a number of questions about it on the SourceForge forums.
 
  E.g. http://sourceforge.net/forum/message.php?msg_id=1889421   (and
  others).   You might want to post a note over there to let people know
the
  status.  (I would do it, but I'm unsure of the status.)