[pmwiki-users] most user-friendly method of database configuration

[Crisses]

On Oct 15, 2006, at 1:09 PM, Pico wrote:

> Ok.  But you didn't really make your case for naming until this  
> post, and so you should understand that the prior exchange may have  
> lacked some important context and substance.

I said I walked in and didn't understand.  I had read back several  
posts, but didn't understand the direction Ben S was going.

I didn't actually apologize for it:  I'm sorry for the misunderstanding.

Having figured out a little about what he was talking about, I  
reframed my contribution to the discussion.

>> Ok, maybe that's not at all where you're going.  If you're not  
>> doing anything regarding user authentication, then maybe I'm wrong  
>> about this.
>
> Why would you be wrong (or right) based on whether Ben S is  
> thinking about user authentication.  If you are right, you are right.

If Ben S is talking about something internal to the recipe, having  
nothing to do with authentication or global uses of databases/ADOdb,  
then I was wrong about my input.  There's nothing wrong with being  
wrong :)

>> For example, maybe your pagestore is on the same server, maybe even
>> the same database, as the authentication that would be accessed by  
>> AuthUserDBase.  Why would the admin repeat the info?
>> Having a unique human-readable label for each database (and  
>> database connection!) would be helpful here.  PHP has this  
>> wonderful way of allowing you to call function and name names by  
>> way of variables.
>> $Databases['moodle'] = array(connection info...); //  $Databases 
>> ['moodle']['type'] is "mysql"
>> AuthUserDBase could have
>> $AUDuse = 'moodle';
>> then (if $$AUDuse isn't defined...):
>> $$AUDuse = new NewADOConnection($Databases[$AUDuse]['type']);
>> Now there's a class instance for that connection named $moodle --  
>> but we never need to know that.  Individual recipes can test  
>> whether another recipe already defined the connection with ADOdb,  
>> creating less class instances that are redundant.  $Databases 
>> ['??'] is optionally human-readable by the admin, and can be  
>> whatever value the admin wants in whatever language, or can be a  
>> code, numbers, etc.  For the programmer it's just a matter of  
>> typing an extra $ and thinking a bit more expansively.
>> This also helps protect the namespace.  How many people are going  
>> to define $db = new NewADOConnection('mysql');
>> straight out of the documentation -- causing potential namespace  
>> clashes between recipes....
>> Are there other concerns?
>
> I would think that the biggest potential problem to be addressed is  
> whether distinctions should be drawn between access db for content  
> and for security.  If you provide unified connection code that  
> fails to distinguish between content used for publishing and  
> content used for security, then won't there be a danger that  
> security information will be inadvertently published?  The issue  
> can arise with two separate dbs, and  can be complicated if the  
> same db contains tables to store content and security data.

This can be handled by the admin.  $Databases can be used for  
multiple authentication levels to the same database as well....

$Databases['mysqlprivileged'] = array( ...for writing to the  
authentication database);
$Databases['mysqlreadonly'] = array( ... for reading from the  
database only);
$AUDuse = 'mysqlprivileged'; // if it's the stand-alone, needs to  
write to the database type of use
$AUDuse = 'mysqlreadonly'; // if it's the read-only type that is only  
authenticating AGAINST the database, but doesn't need to write to it....

> So, in the end, the issue may not really be about providing names  
> for connections so that they can be shared, but in providing a  
> mechanism to distinguish db data intended for publication from data  
> intended for security.

That has to fall on the shoulders of the database admin, too.  I  
could create separate unpriviledged users -- AND SHOULD -- to protect  
the database.  Then I need a way to have multiple database/user  
combos in the wiki.

> As with most of my posts in this area, please keep in mind the  
> running disclosure that I don't know what I am talking about, but I  
> see what I see (like the fool who says the sun is rising, I may  
> just be right).

LOL -- hey, someone saying "sounds good" is better than crickets....

>> You said "each database already has a name" but I don't find $db  
>> to be particularly descriptive or safe.  That's not a "name" but a  
>> storage container used on the programming end, not the  
>> administrator end, of a recipe.  "there can only be one connection  
>> to a given database at a time" -- this is not true.  I can easily  
>> do $db1 and $db2 as two connections, perhaps each looking at a  
>> different table of the same database...
>> If I'm authenticating someone from tableA and you're storing pages  
>> in tableB of the same database, we could share the same connection/ 
>> data -- or we can have multiple connections and duplicated  
>> authentication data.  Databases are all about multiple connections.
>> When writing vbulletin.php I used adodb but the same  
>> authentication as the AuthUserDBase -- so I copied the variables  
>> -- what a waste.  I thought there should be a better way to share  
>> the same info.  Many hosting services only give you one database  
>> to connect to.  Why are admins required to duplicate their data  
>> because the cookbook authors can't agree on one method to share  
>> this data (and maybe even connection!) between their recipes?
>> Whatever we do, we have to allow multiple databases and servers  
>> while making it easier on the administrator(s).
>
> Yes, please.

We're all open to it, which is great.  Problem is getting on the  
phone and having a real conference call about methodology ;)

>> ----
>> Another reason I'm writing is to verify whether you're working on  
>> database-based authentication.  I'm slated to work, alone or with  
>> Ben Wilson, on improving AuthUserDBase and incorporating ADOdb,  
>> etc.  If you're working on it, then I shouldn't.  We don't need  
>> more confusion, Ben & I discussed eliminating confusion by merging  
>> the AuthUserDBase and XesAuthUserDBase recipes.  So I wanted to  
>> check whether or not this is something that is part of your  
>> recipe.  I doubt it, but it's better that I ask.
>
> Ben can answer that, I can't.  But my impression is that we (as a  
> community) will be best served if recipe authors work together to  
> provide solutions that can be layered to work together, and that  
> there is no need to "re-invent the wheel."

Exactly.

I've extended many a recipe or core feature, but I'm all for rolling  
it back in when it's past "does it work" and "is it useful"

> Regards to Jack.

Jack says hi ;)

Crisses
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20061015/c76df81e/attachment.html