[Phpmyadmin-devel] official domain name phpmyadmin.net

[Marc Delisle]

Robin Johnson a écrit :
> 
> On Mon, 8 Apr 2002, Marc Delisle wrote:
> > I am not against using functions, but:
> > - what about the existing arrays in config.inc.php3?
> That is the reason I was using serialize and unserialize to store the
> data. Those functions preserve arrays perfectly.

Ok.

> 
> > - implementing pma_getvariable() all over the code will be a lot of
> > work, so I suggest before starting this, to think also about a possible
> > User Preferences module (db-stored also).
> Could we decide on which of the options in the current configuration
> should be available to each user in their personal preferences?

For example, let's talk about $cfgShowBlob and assume that this can be
a master and a user pref.

I guess you have put a "ShowBlob" field in the config_master table.

It would be more flexible not to have the actual cfg variable names
as fields, but as data, so the config_master table would have 2 fields:
the cfg variable name, and the cfg variable value (possibly serialized).
Maybe a third field to indicate if this can be overriden by the user
(indicating a possible search in config_user).

This is because we have to think about future PMA upgrades and avoid
users having to add fields to config_master.

What do you think of that?

> 
> Since it will just be the redefinition of some of the options from the
> main configuration, I propose doing it like this:
> 
> Read in the master 'config_master' table.
> Read in a client override table 'config_user' which is contains all the
> fields of 'config_master' plus one additional field for the username.
> The options for 'config_user' are set over the existing 'config_master'
> options.
> 
> Voila! You have user preferences. But we would need to put some security
> on that 'config_user' table, as there are probably some things that we do
> not want the user being able to change.
> 
> Also, looking at the security functions of this, as well as the speed
> considerations, using a database configuration system will REQUIRE a
> system that supports sessions, otherwise you risk poor performance
> (re-reading the configuration data on each page). By using sessions, it
> could be loaded once on login, and then re-loaded if the user changes
> preferences.

It is ok for me to require sessions for this, you are right about performance,
and also because this will be an optional configuration mecanism.

Keep on the good work!

-- 
Marc Delisle