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

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> On Thu, 20 Feb 2003 08:34:11 +0100
> Reini Urban <ru...@x-...> wrote:
>>Please do so. Good stuff.

>>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.

Sure. Only optional.

> 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...

ok.

> 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.)

Ok, I'll do.

The current status is that:
Works for me, but not in CVS (disabled there),
and just for my limited set of needed options:
mysql auth with a user table with password.

CREATE TABLE users (
   userid char(48) binary NOT NULL UNIQUE,
   passwd char(48) binary default '*',
   PRIMARY KEY (userid)
) TYPE=MyISAM;

but I will test with that now:
CREATE TABLE users (
   userid char(48) binary NOT NULL UNIQUE,
   passwd char(48) binary default '*',
   pref text NULL default '',
   PRIMARY KEY (userid)
) TYPE=MyISAM;

$DBAuthParams['auth_dsn'] = $DBParams['dsn'];
$DBAuthParams['pref_select'] = 'SELECT pref FROM users WHERE 
userid="$userid"';
$DBAuthParams['pref_update'] = 'UPDATE users SET pref="$pref_blob" WHERE 
userid="$userid"';
$DBParams['dbtype'] = 'SQL';

I'll rewrite it with the abstract base class AuthDB, as you suggested.
Of course the current status (bogo) will be the default auth method.

And I want to test it with phpnuke and other frameworks also
before I commit.
groups and page permissions later.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/