Matthijs Kooijman - #2 - 2007-01-23 18:23 - (Reply)

I’ve given this some thought, and this is what I would care to see. Firstly, the current parsing of .htaccess files should be limitable. In other words, there should be two new configuration directives: allowed_settings and denied_settings (only one can be used, not both). Both can be one of the PHP_INI constants to limit changeable settings to one of those categories (might need some reworking when used with allowed_settings, though). Alternatively, they can be a list of settings that can be changed (or not be changed for denied_settings). This will allow the admin fine grained control over which settings can be changed by users. Secondly, there should be some way for the admins to set configs, probably on a per-directory basis. An obvious choice would be putting .htaccess_admin files in the document root next to .htaccess files, in which all settings are allowed without limits. Admins can use these to set any setting on a per directory basis. The problem with this setup is that nothing wil prevent users from creating these admin files. Checks could be added for the owner or permissions of these files, but a system like this will be shakey at best. A better option will probably to add a single config file, that can contain any admin settings (let’s call it the "admin config" file). To support per-directory configs, one can allow for something like lighttpd’s conditionals, but simpler (only matching the script name and only doing prefix matching, for example). This creates a solution that is probably powerfull enough. One remaining problem, at least in my setup, is that this will require a single admin config file for the entire server. In particular, I have a number of different fastcgi servers running as different users. They will all use the same php.ini file and thus the same htscanner configuration and thus the same admin config file. This file could contain a huge list of config directories, using path-based conditionals to apply the directives to the correct subdir/vhost. Yet having this monolithic file is not really a good idea. Options that cross my mind are making the admin config file location relative to the document root (but since users usually have write access to the document root, this might be a bad idea, perhaps supporting ".." in the path might help…) or allowing to include other php.ini files from the admin config file (so I can give every fastcgi server their own php.ini without losing the ability to defaults). Not sure what exactly is a good idea here (or what I want to have even…)