[OpenSIPS-Users] OpenSIPS Control Panel 8.2.4 was released

[Bogdan-Andrei Iancu]

Hi John,

Thanks for all your testing - this is something that we so most 
appreciate ;).

To help us even more, could you please split the report (you have in the 
email) as individual issues and create corresponding tickets on github:
         https://github.com/OpenSIPS/opensips-cp/issues

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 11/05/2018 04:59 PM, John Quick wrote:
> Hello Bogdan,
>
> Thanks for releasing a new version of the Control Panel. There are some
> great new features in this version that I want to try.
>
> I have been testing OCP v8 on a CentOS 6 server. I'm finding quite a lot of
> errors - it is possible some of these are associated with the operating
> system or the version of PHP I am using. PHP is v 5.3.3
>
> The most critical problem for me concerns administrator access: I am unable
> to change the password for the admin user.
> As a precaution, I created a new admin user with a different name and then
> tried to revoke the key privileges of the original admin user, but this made
> no difference until I edited the source code and changed the tool name
> passed to the get_priv() function as detailed below.
>
> Here are my full notes on the problems encountered so far and code
> adjustments I have made:
> In login.php: Warns me "It is not safe to rely on the systems timezone
> settings. You are required to use date.timezone or
> date_default_timezone_set() function".   As a work-around, I added calls to
> date_default_timezone_set("Europe/London") in a couple of places to stop
> these warnings being written.
>
> Many of the tabs display a blank page. In the httpd log file; the httpd log
> files shows errors about "unexpected [".  When I look up the file and line
> number shown in the httpd log message, it's always a line that calls the
> die() function to handle failure of an SQL request.
> I found it was due to the use of "errorInfo()[2]".  If you remove the [2],
> it doesn't give an error and the page is rendered too.
>
> Used grep to find every case like this:
> 	# grep -rl "errorInfo()\[" .
> 	./users/user_management/template/user_management.main.php
> 	./users/acl_management/template/acl_management.main.php
> 	./system/dialplan/template/dialplan.main.php
> 	./system/dialplan/dialplan.php
> 	./system/siptrace/template/tracer.main.php
> 	./system/drouting/template/groups.main.php
> 	./system/drouting/template/rules.main.php
> 	./system/drouting/template/carriers.main.php
> 	./system/drouting/template/gateways.main.php
> 	./system/drouting/lib/carriers.test.inc.php
> 	./system/drouting/lib/carriers.functions.inc.php
> 	./system/tls_mgm/lib/data_loader.php
> 	./system/loadbalancer/template/loadbalancer.main.php
> 	./system/dispatcher/template/dispatcher.main.php
> 	./system/dispatcher/template/dispatcher.form.php
> 	./system/tviewer/lib/data_loader.php
> 	./system/callcenter/lib/data_loader.php
> 	./admin/list_admins/template/list_admins.main.php
>
> Admin Access Control
> I cannot find a way to change the admin password. It always accepts the
> password of "opensips" even after resetting it in the Admin User editing
> form and also deleting it from the field "password" in the
> ocp_admin_privileges table. On further testing, I then found that none of
> the changes I make to the admin user get saved to the DB - not just the
> password, but also the first name and last name fields.
>
> Access privileges were not working to restrict whether the logged-in user
> could change their own (and other people's) admin privileges.
> Found this was because the get_priv() function was being called with the
> argument set to "list_admins" and that the arrays used to store access
> privileges only have a key called "user_management" and do not have one for
> "list_admins".  There are no lines of code to act as a "catch-all" in the
> get_priv() function so if the tool name passed to the function does not
> match any of the known tab names, then it fails to set the session variable
> read_only. The absence of any value is then treated as "grant full access"
> in the corresponding module so it is not very safe.
> As a work-around, I edited web/tools/admin/list_admins/index.php and changed
> the following line:
> << get_priv("list_admins");
>>> get_priv("user_management");
> John Quick
> Smartvox Limited
>
>