* Fixed: #2964 to add missed argv for all rrd_function_graph caller
* Fixed#2964: Apply security solution to aggregate graph preview and graph impage page
* Realtime log non ordinary message
* This is new in develop. Therefore, no CHANGELOG
* Also, don't log to standard output when updating single data source in boost. It breaks REALTIME.
* Moving all argument composition for backgrounded calls of php to 'assemble_php_args()' in /lib/functions.php.
* lib/functions.php: Explicitely prepending all assembled arguments.
* lib/functions.php: Removing an accidental appending of the initial args in assemble_php_args().
* Introducing the prepending of the current php.ini file, if any, to the extra arguments of backgrounded php calls (used with exec_background).
This enables the backgrounded process to stay in the same environment as the main one and not default back to a system wide default configuration file (which might or might not have configurations setup properly).
* Prepending the current php.ini in use (if any) to any exec() or shell_exec() call, that is doing a backgrounded call of the php executable.
* graph_realtime.php: Fixing missing whitespace between executable and first argument.
Resolving this and a few other minor memory leaks. Everything should
and have been validated to be working properly now. There were a few
additional issues I found in performing a full regression.
also fixed some dependencies.
realtime graphs still not working though.
Are we deprecating this feature ? Its not as nice as the other one, but i like the popup feature.
If you are running in development, you have to issue these two commands
rename table settings_graphs to settings_user;
rename table settings_graphs_group to settings_user_group
There are still three steps to go in this overall. The first is to
replace all the page filtering session storing and validation functions
and the second is to propagate those changes into various areas of the
lib directory that include the use of the various variables, lastly,
developer mode will have to be enable to see if there are any variables
used in the code that have not been sanitized. Note, at this point the
develop branch should be thought of as slightly unstable
this is part three of project to remove the use of $_GET, $_REQUEST, and
$_POST in the code. Parts one and two have already been completed.
Part one was to remove the use of $_GET throughout the code, part two
was the incorporation of wrapper functions to handle specific
validation, verification and sanitization cases. This third part will
remove the use of the get_request_var_request() from the code. Part
four, and beyond will include the removal of both $_REQUEST and $_POST
super globals from the code.
netniV