Since I liked all solutions I implemented all auth methods and policies,
with the correct auth method dispatchers.
It worked okay, until I disallowed ALLOW_ANON_USER (and/or ALLOW_BOGO_USER).
since then we have no user object and therefore no pref object.
This will need some more work.
I added yet another auth policy "old", which mimics the current
behaviour, and tries to be smart with the given auth options and
available php functions.
Attached is the corresponding index.php excerpt, and the new classes,
without the minor neccessary main.php changes.
developers: please review it.
PS: maybe it's just me, but the cvs.sf.net ssh connection is very
unstable in the last weeks, and I cannot do
cvs up, cvs diff or cvs commit lib/WikiUserNew.php.
and the host keys did change almost every day, which is a pain with openssh.
Reini Urban schrieb:
> I'm just finishing the new wikiuser authcode and came to this question:
> In the current code the authentification methods are "stacked", that
> means, that the methods are searched in a predefined search order
> (e.g. Anon or Bogo or HomePage password => ldap => imap => http_auth).
> The first method which returns true is taken. False is only returned if
> all defined methods will fail.
> With my new code we allow even more auth methods:
> internal db, external db, file
> Now how should the admin configure his authentification:
> 1) Should he be able to define the search order?
> 2) Should he be able to define stacked (policy c) or strict (policy b)
> or pre-defined method order (policy a)?
> The problem is that the user may exist with the current method but the
> password is wrong, which brings him to the next method. This might not
> be wished for certain auth methods were the username and password must
> match and no other methods may be tried if the username exists in the
> databse but with the wrong password. For example the database password
> is wrong, but a file password matches is ok.
> Currently the order of first three methods is fixed:
> Anon if defined, Bogo if defined, User if defined.
> Those three methods are stacked.
> With the new methods in the new auth classes (called if
> ALLOW_USER_PASSWORDS is defined and the previous methods failed) one
> could define policy c: a stacked scheme ("try next method if it fails"),
> or policy b: a stricter scheme ("check user and if she exists the
> password, on failure try no other methods").
> To make thing even more complicate my current code makes use of only one
> pre-defined external auth method (policy a), which simply upgrades the
> user class in the constructor, and not in the checkUser() or
> UserExists() methods.
> How to define the auth policies in index.php?
> One could easily define a new config variable like
> which defines the strict scheme, and if not defined
> the stacked scheme will be used.
> The simple problem is that then we will have to define one more method
> for all user classes:
> Currently we need only ->checkPass() and optionally ->storePass().
> The code for a simple predefined scheme, (not-stacked) scheme is now
> ready, were only one auth method is predefined, for all users.