[dokuwiki] Re: MySQL auth
- From: Matthias Grimm <matthiasgrimm@xxxxxxxxxxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sun, 29 Jan 2006 20:15:59 +0100
On Sun, 29 Jan 2006 14:08:51 +0100
Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote:
> I just updated wiki.splitbrain.org, and as promised I have some things
> I'd like to discuss about the MySQL auth backend:
>
> 1. The encryptPass option description or name is misleading:
>
> "Set 'encryptPass' to '1' and the cleartext password is forwarded to
> the database, otherwise the encrypted one."
The name is correct from the MySQL point of view. It means that the
database should do the encryption. I see that the short name is
something misleading but I didn't want to name it
database_does_the_password_encryption.
> I think the option should be named clearPass then!?
This won't make it more clear. Only the point of view changed. We need
a more descriptive name like encryptPassByDB, passwordencryptionByDB or
similar.
> 2. UpdateLogin is questionable - should changing the login really be
> supported? It doesn't work in the plain backend anyway.
Yes, for sure. The user login can only changed by admins in the user
editor. The user name might contain a scribal error that needs to be
corrected or the name of a user changed and the login name should
change accordingly. The classic way you need to delete the old user and
create a new one instead of simply change it's user name and keep the
rest of the data set.
I would vote for adding this functionallity in plain backend as well or
at least emulate it.
> 3. I'm not sure about the UID either - it isn't used in the most
> statements. Instead the login is used which has to be unique to login
> anyway. Why not get rid of the getUID statement completely and use the
> login as unique identifier everywhere. A statement less to configure,
> and more like the plain auth.
The UID makes the database design much more elegant, straight forward,
less memory consuming and easier to maintain. The UID is the only data
field that will never ever change in a dataset. References to UID can't
become invalid (except you delete it) and the best: The database handle
this key field automatically.
You are right if you say the the login name is unique too, but if we
use the login name here, we must also use the login name in the
usergroup table. We use the same memory consuming strings in two tables
and create redundant data. The next step would be to merge the group
table into the usergroup table. Doing this would mean to ignore the
fundamental rules of database design.
Furthermore the database code would become a little bit more complex
and performance would slightly decrease. I think to accept all this
disadvantages only to save a single field wouldn't be worse the effort.
> 4. The docs should say which statements are needed for what. Eg. only a
> few statements are needed for logging in. A few more are needed to add a
> user, another few are for modifying... It should be enough to only
> define the ones one want to provide support for.
Agreed. This will be helpful.
> 5. Related to 4 the MySQL should override the canDo() function to return
> if a feature is configured - the GUI can adopt then...
Of course ... I did't realize the the interface is already defined
completely.
> 6. Do multiple statements in delUser work? I may need to clean multiple
> tables...
Yes.
> 7. Some config strings start with a lowercase letter other with an
> uppercase one -> all should use the same. Maybe we should lowercase
> those keys completely?
Don't think so. To inrease the readability of config options I start
always with a verb in lower case followed by a subject in camel case.
The options starting with a capital letter don't work for their own.
They depend on another statement. For example FilterLogin will be added
to the getUsers statement and will never be sent to the database solely.
To begin subordinated statements with a capital letter was not my best
idea, I agree, but I want to seperate them visually from ordinary
statements. I want them to look different. If you have a better
suggestion...
Best Regards
Matthias
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
