Since upgrading to 4.1.1 when I clicked on Administration -> Backup and clicked on "Create Backup," It shows a white screen and states "Not authorized!"
Thanks for any help.
Jeff Guillory
NP Health Clinic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did lots of ACL testing with that new fix before the release and it looked good. However, just hit me what is likely happening here. For example, in Administration->ACL, if you place the Demographics ACO in both the addonly and write return ACL bad things will happen. Which makes total sense, because return $gacl_object->acl_return_value() will try to return two values (I am not sure what is actually does, but whatever it returns, it breaks the code. So, an aco should only ever be in one ACL of the same group; if it is in more than one return value acl of the same group, then bad things will happen.
That will break things where doing acl_check and seeing if equivalent to addonly or write etc.
That being said, I have not been able to reproduce why the backup script is breaking, which uses:
if (!acl_check('admin', 'super')) die(xl('Not authorized','','','!'));
The question here is that does it make sense to revert the 4.1.1 release back to the original acl_check function until this is sorted out (for example, could make the Administration->ACL script not allow ACO's in more than one group return value and issue warnings if currently the case.
Did some testing and turns out that the $gacl_object->acl_return_value() function only return one return value and it chooses the most recently added one. So, if I were to add the demographics ACO to write, then to addonly, this means a user would not be able to edit the demographics (only has addonly privileges).
And this actually gets much worse. Because a user can be added into multiple groups, so there is simply no way to control which return value is given back if the user has different return values in different groups.
I think we need to revert to old acl function and rethink this. I think the way to go is not to request the return value from the gacl function $gacl_object->acl_return_value() when looking for a specific return value since this does not work. We need to collect all the permitted return values and then see if one of them is the one we want (such as write, addonly etc.). This may require a small bit of code mod in gacl itself, but I think this may be the way we need to go(could potentially modify/rename the gacl acl_return_value function a bit by adding a parameter for the return value to check for and then to simply return a true/false; note would require modifying codebase to place the specific return value in the function parameter rather than test equality of it).
Since upgrading to 4.1.1 when I clicked on Administration -> Backup and clicked on "Create Backup," It shows a white screen and states "Not authorized!"
Thanks for any help.
Jeff Guillory
NP Health Clinic
I think that this commit:
https://github.com/openemr/openemr/commit/41063da81582a7b07814917cf2f16d17f14fb322
which reverses some ACL changes in the 4.1.0 patch sequence also needed to be addressed for 4.1.1.
My suggestion for a quick fix would be to download the 4.1.0 patch 13 version of library/acl.inc from here:
https://raw.github.com/openemr/openemr/rel-410/library/acl.inc
and replace.
Thank you yehster, that did fix the "not authorized" problem.
I still cannot download the backup though. I still get the error: File not found Firefox can't find the file at https://server/openemr/interface/main/backup.php.
as discussed on this thread: https://sourceforge.net/projects/openemr/forums/forum/202505/topic/4919698
Any help would be appreciated in this matter also.
Thanks again.
Jeff Guillory
Hi,
I did lots of ACL testing with that new fix before the release and it looked good. However, just hit me what is likely happening here. For example, in Administration->ACL, if you place the Demographics ACO in both the addonly and write return ACL bad things will happen. Which makes total sense, because return $gacl_object->acl_return_value() will try to return two values (I am not sure what is actually does, but whatever it returns, it breaks the code. So, an aco should only ever be in one ACL of the same group; if it is in more than one return value acl of the same group, then bad things will happen.
That will break things where doing acl_check and seeing if equivalent to addonly or write etc.
That being said, I have not been able to reproduce why the backup script is breaking, which uses:
The question here is that does it make sense to revert the 4.1.1 release back to the original acl_check function until this is sorted out (for example, could make the Administration->ACL script not allow ACO's in more than one group return value and issue warnings if currently the case.
thoughts?
-brady
OpenEMR
Hi,
Did some testing and turns out that the $gacl_object->acl_return_value() function only return one return value and it chooses the most recently added one. So, if I were to add the demographics ACO to write, then to addonly, this means a user would not be able to edit the demographics (only has addonly privileges).
And this actually gets much worse. Because a user can be added into multiple groups, so there is simply no way to control which return value is given back if the user has different return values in different groups.
I think we need to revert to old acl function and rethink this. I think the way to go is not to request the return value from the gacl function $gacl_object->acl_return_value() when looking for a specific return value since this does not work. We need to collect all the permitted return values and then see if one of them is the one we want (such as write, addonly etc.). This may require a small bit of code mod in gacl itself, but I think this may be the way we need to go(could potentially modify/rename the gacl acl_return_value function a bit by adding a parameter for the return value to check for and then to simply return a true/false; note would require modifying codebase to place the specific return value in the function parameter rather than test equality of it).
-brady
OpenEMR
So you recommend I replace that file with the one from the backed up openemr 4.0.11 file?
Jeff
I replaced the acl.inc file with the backup file from openemr4.0.11. This did not help. Still getting the "Access not allowed" error.
The title over the box that pops up is: "https://server.com/openemr/interface/main/calendar/add_edit_event.php?startampm=1&starttimeh=10&userid=2&starttimem=15&date=20120914&catid=0" I hope that can help.
Seeing patients without the scheduler working is very tough. It is essential for smooth office flow.
Thanks again to anyone who can help.
Jeff Guillory
NP Health Clinic
Hi Jeff,
Considering the critical nature of this bug, just released a new 4.1.1 patch with this fix in it:
http://www.open-emr.org/wiki/index.php/OpenEMR_Patches
Also placed this issue on the Active Project wiki page:
http://www.open-emr.org/wiki/index.php/Active_Projects#Return_Values_Bug_Fix
-brady
OpenEMR