Generally using xml instead of ini format would allow many things
-different ini sections for different sapis
-different ini sections for different users
-maybe inclusion of subscripts (db admin may change only database parts..)
-maybe different ini sections for different webservers if we can
distinguish before loading ini
-and other handling other differences we may have now or will have to
handle in the future.
but first of all we should have a dtd or xschema for this
and then xml parsing is slower than ini parsing
and the components needed to parse the xml settings file have to be all
core components (without usage of external libraries)
and that would violate thinks like --disable-xml
besides that i would agree but my guesses are that no one will be found
doing all
the code changes
(i skipped reply to general list because i only reply to means of development)
marcus
At 21:31 16.05.2002, Michael Dransfield wrote:
I have started writing an app which helps (mainly win32, new) users to
generate config files correctly to prevent glaring security holes on
production servers.
I started by using parse_config_file(), but this ends up causing problems
because it strips comments. This means that some variables which are
commented are lost from the program. There are also potential problems
because some of the config file has [sections] and some of it
doesnt. Some of this is valid in win32 environments and some are
not. This can cause problems if users download the win32 default config
file and then upload it to Linux or BSD, it will fail.
Will uncommenting some of the variables (and then setting them to the
default) affect the running of php at all? is there a reason why they are
commented and not just set with their default / NULL value?
I then began playing with an xml file which stores the comments and
variables along with other useful information relating to the
configuration variable. I then added warnings to the XML document so that
the front-end can read if a setting is potentially insecure (in the
current environment). I think the best way to explain it is by looking at
the attached file, most of it is obvious, i have commented where necessary.
Do you think this format looks OK, I am sure i have missed a lot of
information which could be of interest, for example storing a default
value with each variable, which could be different in different
environments (eg default env=dev value=1/). Maybe add a severity to
the warning.
What would you think about the possibility of including the XML ini file
format in later release of php? it is easy enough to parse the file when
the server is started as easilly as it can parse the current ini
file(?). It could enable many possibilities because is can store multiple
environments within it, along with relavent information about the setting
itself, which would make overall administration much much easier, and
quicker. ini files are s Windows 95, dont you think?
I am going to write the front-end as a web application and as a php-gtk
app (hopefully with the same code).
Does anybody have any comments or suggestions (or would like to
help)? (please try to keep them constructive ;) i have looked for
similar projects, but cant find any.
Regards
Mike
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
