Several new changes with phpGACL in CVS version of OpenEMR:
-Can now add users to phpGACL groups from within OpenEMR. Here are the screenshots: http://www.sparmy.com/pics/screenshot1.jpg http://www.sparmy.com/pics/screenshot2.jpg
These are multi-selection boxes, so users can be placed in more than one group if needed.
(Don’t worry, ‘admin’ is not allowed to remove themselves from the Administration group.)
-I wanted to keep the ‘out of the box’ OpenEMR phpGACL access controls as standard as possible to avoid losing functionality(for example if I was using version 2.8.1 and just simply upgraded OpenEMR to 2.8.3 I would never see the new encounter ‘sensitivities’ functions). So, added a acl_upgrade.php script, which can be used when upgrading versions of openEMR. It basically upgrades the phpGACL object controls of any version from 2.8.1 of OpenEMR to the most current. Here’s a screenshot: http://www.sparmy.com/pics/screenshot3.jpg
If a developer wants to add a new phpgacl object into the codebase, they should then add it to the following files to ensure it works ‘ot of the box’:
acl_upgrade.php
acl_setup.php
library/acl.inc (just put in header comments for reference)
hey,
Either one seems to be fine. Have tested with both 3.3.6(which is on the appliance) and with 3.3.7(in my development environment). If you have the option I’d go with the newer one, since the phpgacl website reports it includes “several minor bug fixes…”
-brady
hey,
I think all the bugs are fixed, and the ACL administration page works with IE/firefox and php5/php4. To ensure proper function with AJAX, make sure php.ini file has display_errors=Off. Let me know if you find any bugs.
-Brady
Wow. It really looks great. I got acl working yesterday so this morning, it occurred to me to try the ‘ACL’ link. I spent a minute just pushing the edit/hide link to watch the visual effect.
Good job on on getting acl administration into openemr.
If this sort of special effect were sprinkled around the main parts of openemr, it might be a good selling point.
For those providing commercial support, I imagine during a sales call, a doctor or administrator falling asleep during the presentation might wake up and pay attention when they see stuff like this.
I was thinking it was about time to completely embed php-gacl within openemr. php-gacl doesn’t seem to be maintained anymore, and it would make installation much easier. This would turn openemr into a one-step installation now that freeb and sql-ledger are no longer required.
Here’s the proposed plan:
1. Copy php-gacl(version 3.3.7) into openemr (/gacl directory)
2. Point /openemr/library/acl.inc link to /openemr/gacl directory
3. In config for phpgacl (gacl.ini.php and gacl.class.php) edit following:
db_host = ""
db_user = ""
db_name = ""
db_table_prefix = "gacl_"
4. Merge the phpgacl setup.php file into OpenEMR’s install setup file (most time-consuming step)
-will need to give edit priviledges to gacl.ini.php and gacl.class.php during install (just like openemr’s sqlconf.php file)
-will need to give edit priviledges to /gacl/admin/templates_c directory by webserver before running install script
-will run acl_setup.php script at end of openemr install script
-will give the initial user administrator priviledges
5. Secure the gacl admin page at /gacl/admin/acl_admin.php and embed into openemr
-link this to the admin->acl in OpenEMR with a ‘Advanced Options’ link
6. Some documentation changes
The cool thing about this plan is that it won’t break php-gacl if already installed (just point /openemr/library/acl.inc to it)
QUESTION TO OTHER DEVELOPERS:
Are we ok with putting the php-gacl database in with the openemr mysql database with the gacl_ prefix. I’m not seeing any big security issues with this, but want to make sure. The advantage is it’s much easier to install this way(than by having to making a new mysql user and database).
I’m already including phpgacl in the installation for our hosted clients, but another option for the future might be to switch to Zend_Acl and Zend_Auth parts of Zend Framework. It is actively maintained and there are a lot of other classes in ZF we might take advantage of to improve the code base.
Sounds like a great idea. phpGACL seems to have been abandoned a few years ago. Perhaps they reached their desired level of functionality and just stopped?
That’s a great idea! I have been including the gacl tables in my OpenEMR installation per Rod’s advice. I had a issue a while back with a single database user name trying to connect to two databases (openemr, gacl) . Bringing the gacl tables into openemr db (with gacl_prefix ) solved my issues.
php-GACL is now officially embedded in OpenEMR (cvs version). php-GACL now gets automatically installed/customized during OpenEMR’s setup.php script. The setup.php script is functional but not very pretty right now; plan on making some changes to make it more clear. Let me know if there are any bugs (I’m especially curious if works on microsoft).
If anybody’s curious, php-GACL and OpenEMR are kept in same mysql database and php-GACL gets ‘gacl_’ prefix. I also secured the embedded php-GACL admin pages with itself (the way it should be). There’s an ‘advanced’ link in the OpenEMR admin->acl menu that will link you to the php-GACL admin pages (I spent at least twenty minutes entertaining myself by editing access controls in the OpenEMR acl admin, and watching it then change in php-GACL admin page). At the end of the day, editing access controls is much easier thru OpenEMR acl admin, but it’s nice to have the php-GACL admin easily accessible for debugging etc.
Where’s that statement, I think i did that a long time ago. As I recall there are strange bugs when remove all of groups (or it may be all acls or acos). Once i see the context of the code, I should remember.
You’ll find those lines of code in <oemr>/interface/usergroup/user_admin.php
Since I’m not using the built-in username/password authentication I’m not sure if there is a problem. I developed an Active Directory (AD)authentication piece which is used in my Agency. That, in combination with phpGACL, is what I use for authentication and authorization. I have quite a few users in the OpenEMR database which are not in phpGACL. So they can authenticate just fine, via AD, but can’t get in the front door because they are not a member of any group.
hmmm… Now that I’m thinking about it… I added a phpGACL group check to the <oemr>/library/auth.inc so that a system using phpGACL will not allow a user to log in if they are not a member of any group. This was put in place because of a security issue. Somebody without any group membership could previously enter the system and roam around. So I added the group-membership check. Here’s the code snippet from auth.inc:
function authNewSession ($user, $pass, $provider)
{
// check to see if the user belongs to *any* OpenEMR groups in phpGACL – JRM
global $phpgacl_location;
if (isset ($phpgacl_location)) {
if (acl_get_group_titles($user) == 0) return false;
}
…
hey,
After looking thru the code, I’m glad you mentioned this. Back when I made this code I actually forced users in a group back to avoid the strange behavior when users weren’t in any groups (which is no longer an issue with your code in auth.inc). I’m definitely gonna nix that code, but the real bug is in another line of this file, which won’t allow removal of all groups if you select nothing in the SELECT(access_group):
if (isset($phpgacl_location) && acl_check(‘admin’, ‘acl’) && $_GET[“access_group”]) { set_user_aros() }.
(if access_group is NULL, then doesn’t even get run).
With this theme I also don’t let all groups get removed from user in admin->acl, and I’m a bit worried I may of set up the same thing in the set_user_aros() function.
I do agree we should be able to remove all groups from users, so will put these fixes on my bug list.
As an aside, I’ve also got the same code in usergroup_admin.php file, but ok for new users. In that file I’ll probably leave the administrator as default selection, but definitely up for debate.
While removing users from all groups should be an option, this is definitely not a straighforward mechanism to make users inactive. This should be done with the ‘active’ toggle in user administration, which doesn’t work. (if I untoggle it, the user can still log on). Not allowing these users to log on would be a beneficial addon to auth.inc.
I wasn’t aware of the ‘active’ flag in the users table. I just adjusted the auth.inc code to check for that flag and reject any user whose active flag is not set to ‘1’.
Just committed the changes to remove the default choice in user_admin.php and committed changes to allow removal of all groups from users (the only thing it won’t allow is removal of the ‘Administrators’ group from the ‘admin’ user).