Revision [3297]

This is an old revision of WikkaSecureConfig made by NilsLindenberg on 2004-12-16 09:47:24.

 

Securing the configuration

The current process for Wikka configuration is not only HandlingWikkaConfig hard to understand (and thus hard to adapt), it was also WikkaBugs 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

  1. The configuration contains sensitive data (database access); preferably this should be stored outside of the webserver docroot.
  1. This implies that a path must be known (to wikka.php) where to find the configuration file.
  1. 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
  1. The package should come with a "basic" configuration file in the same directory as wikka.php; BUT with different name than "actual" configuration.
Better in the setup-directory. It is an installation file, at least. --NilsLindenberg
  1. Installer should read this basic config and provide WikiAdmin with an interface to:
    1. define a path for the "real" configuration file to be stored;
    1. adapt provided default settings;
    1. define extra required and optional settings.
  1. Installer then writes a config file with the new values to the defined path.
  1. Installer writes the path to wikka.php (in the same way it writes the version number).

Upgrade
  1. The basic installation file will be overwritten with a new version from the archive (there may be new required settings).
  1. The (current) configuration path is read from wikka.php and used to retrieve the current configuration.
  1. All configuration data are then 'merged' with those from the current configuration file (configuration file taking precedence over default).
  1. As with installation, an interface is provided to update settings and (re)define the path.
  1. Write out new configuration to the (new) path.
  1. Update (new) path into wikka.php.

Advantages

This approach has the following advantages:

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

CategoryDevelopment
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki