Revision history for WikkaSecureConfig
Revision [22990]
Last edited on 2016-05-20 07:38:44 by JavaWoman [Replaces old-style internal links with new pipe-split links.]Additions:
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.
Deletions:
Revision [18442]
Edited on 2008-01-28 00:11:29 by JavaWoman [Modified links pointing to docs server]No Differences
Additions:
====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:
~- 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:
~~1)The database is at least accessible to retrieve an email address from.
~~1)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
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:
~- 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:
~~1)The database is at least accessible to retrieve an email address from.
~~1)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
Deletions:
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:
~- 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:
~~1)The database is at least accessible to retrieve an email address from.
~~1)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
----
CategoryDevelopment
Additions:
~~''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
Deletions:
Additions:
~~''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.
Additions:
~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).
Deletions:
Revision [3298]
Edited on 2004-12-16 10:51:33 by JavaWoman [possible solution for missing config values]Additions:
''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. In complete 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., as the database access parameters.)
~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:
~~1)The database is at least accessible to retrieve an email address from.
~~1)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
~The 'default' config as stored in wikka.php now is incomplete anyway: the system cannot work without database access. In complete 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., as the database access parameters.)
~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:
~~1)The database is at least accessible to retrieve an email address from.
~~1)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
Deletions:
Additions:
~~''Better in the setup-directory. It is an installation file, at least.'' --NilsLindenberg
Deletions:
Additions:
~~''Better in the setup-directory. It is an installation file, at least. --NilsLindenberg
~- no need to merge the default and userconfig up to four times
''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
~- no need to merge the default and userconfig up to four times
''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
Additions:
~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) adapt provided default settings;
~1) define extra required and optional settings.
Deletions:
1) adapt provided default settings;
1) define extra required and optional settings.
Additions:
Comments and ideas for improvements are welcome, of course.
Deletions:
Additions:
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.
~1) The (current) configuration path is read from wikka.php and used to retrieve the current configuration.
~- no need for (insecure) ""GetEnv()"";
~1) The (current) configuration path is read from wikka.php and used to retrieve the current configuration.
~- no need for (insecure) ""GetEnv()"";
Deletions:
~1) The (current) configuration path is read from wikka.php and used to retrieve the current
configuration.
~- no need for (insecure) GetENV;
