Securing the configuration
The current process for Wikka configuration is not only hard to understand (and thus hard to adapt), it was also pointed out that it currently uses GetEnv() which constitutes a security risk. Besides, storing the configuration file in a place that's accesible by a browser (i.e., below the web server's docroot) is itself a security risk since it defines the access credentials for accessing the database.Here are my thoughts about a more secure and at the same time more flexible way of dealing with Wikka configuration.
Reasoning for a new approach
- The configuration contains sensitive data (database access); preferably this should be stored outside of the webserver docroot.
- This implies that a path must be known (to wikka.php) where to find the configuration file.
- During install/update the path could be defined (by WikiAdmin) and written into the code in wikka.php (as a define).
Below a description of the (possible) logic for implementing this.
Installation
- The package should come with a "basic" configuration file in the same directory as wikka.php; BUT with different name than "actual" configuration.
- Installer should read this basic config and provide WikiAdmin with an interface to:
- define a path for the "real" configuration file to be stored;
- adapt provided default settings;
- define extra required and optional settings.
- Installer then writes a config file with the new values to the defined path.
- Installer writes the path to wikka.php (in the same way it writes the version number).
Upgrade
- The basic installation file will be overwritten with a new version from the archive (there may be new required settings).
- The (current) configuration path is read from wikka.php and used to retrieve the current configuration.
- All configuration data are then 'merged' with those from the current configuration file (configuration file taking precedence over default).
- As with installation, an interface is provided to update settings and (re)define the path.
- Write out new configuration to the (new) path.
- Update (new) path into wikka.php.
Advantages
This approach has the following advantages:- no need to have default configuration stored in the main program (wikka.php): it's used only during installation/upgrade;
- allows storing configuration outside of docroot;
- no need for (insecure) GetEnv();
- the logic of this approach is independent of implementation of configuration (PHP array or INI file); migration to a more user-friendly INI file will be possible without changing the logic.
- no need to merge the default and userconfig up to four times
Comments?
Comments and ideas for improvements are welcome, of course.the only disadvantage i can see is the case of an incomplete config. With that I mean options missing. Imagine for example a webmaster who removes an entry which he thinks unnecessary, or he removes the wrong one, or the file is damaged... It is unlikely to happen, but not impossible. So we should take care that functions who work with config-options have a default.
I started rewriting the installer, look on my userpage, but is isn't finished cause I had the intention to divide install and upgrade, which makes more work then I thought of. --NilsLindenberg
The 'default' config as stored in wikka.php now is incomplete anyway: the system cannot work without database access. Incomplete config is not a disadvantage of the proposed logic - the problem exists now as well. Besides, not every configuration variable can have a default value (e.g., database access parameters).
I know that. I've written it on HandlingTheConfig. What I mean with incomplete is a missing default for an option. Example: a webmaster wants no link-tail for external links and therefore delets simply the whole entry in the config. Wikka should work with things like that (i.e. in this case adding nothing to an external link). May be that this is the case now, but I just wanted to mention it. --NilsLindenberg
A possible solution for when a required value is missing would be:
- Display a message to an end user that the system is currently unavailable;
- Send an email to the WikiAdmin(s) to notify them of the problem;
- When an Admin logs in, immediately switch to configuration maintenance interface.
This assumes two things:
- The database is at least accessible to retrieve an email address from.
- We can see the difference between an ordinary user and an Admin user. (IOW, this should not be dependent on a configuration file but be stored in the database.)
So these data must be available in the database, too, to retrieve Admin status for a user and Admin email address(es).
If even this fails (no database access), we could post an (encrypted) primary email address to contact the Admin on the user error page, asking them to notify the Admin via this address; this address should then be written to wikka.php (in the same way the path for the configuration could be written to the program file) so it's always available. --JW
CategoryDevelopmentArchitecture
