A problem with using Civi for a members’ website based on Joomla is the need to be able to control access for different types of user – for example you might want ordinary members to be able to edit their own details but not see the details of other members for privacy reasons. But perhaps some groups of members might want to see each others details. Then you might have some users (eg the committee) who should be able to search and view all members, and others (eg the membership officer) who are allowed edit any user’s details. You don’t really want to let any of these people loose on the backend, so you need to be able to grant access to profile forms on the front end based on their credentials.
The ideal solution is either to get CiviCRM’s ACL system working on Joomla, or to wait until Joomla 1.6 comes along with its own more fully featured ACL system – unfortunately I needed a quick solution that would provide a level of privacy and security to satisfy the organisation.
First up, this is a members only site – so the Joomla component CiviUser is used to restrict online registration to only people with a valid current membership record, and the CiviAuthenticate plugin is used to ensure their membership is still valid every time they log in. So there is no public access required to any of the CiviCRM side of things.
This also means that every Joomla user has a contact match in CiviCRM, although not every CiviCRM contact has a corresponding Joomla user. Members can set up their own registration, but their email address has to match a contact record.
The approach I took was to try and make modifications only to the Joomla specific parts of Civi, so that upgrades to either Joomla or the Civi core should not stop it working. The key thing is the front-end Joomla component file – civicrm.php – this is the entry point for all front-end access to Civi functions, so if we can impose some policing there we should be able to stop most of the unwanted access to data.
There are two possible sets of attributes of a logged in user that could be used for permission control – on the one hand all users belong to a Joomla user group (guest,registered,author,editor,publisher,manager,admin), or on the other hand the Civi contact may belong to several different groups or tags.
In practice I chose to use both methods – each Joomla user group can have a specified list of profile forms which they are entitled to use, and each menu entry can be restricted to only a specific Civi user group (including smart groups). This is in addition to the normal public/registered/special Joomla restrictions on menus.
The problem with relying on menu restrictions is that this does not stop a knowledgeable user bypassing it by constructing a url that has the right query string to directly access the profile. Of course you can obscure things by using SEF links, but Civi itself exposes the full details in the address bar, for example when you click on the search button or the view link in a profile list.
Hence my first line of defence is to restrict menu links by Civiuser group, but then the second line is also to restrict access to profiles by id based on the Joomla user level - this works independently of whether the page is accessed by a menu or a direct link.
The final piece is to restrict who can see and use edit links – again I use the Joomla group, setting a minimum level which is allowed access to edit forms (all users get access to edit their own details anyway). This has involved modification to two core Civi files.
It is not perfect, and it is difficult to explain in even in a long blog post, the future answer is to get an ACL system (either Civi or Joomla) working which controls access to any resource on a per-user as well as group basis, but the system described here is working ok on a couple of sites.
You can download it as a Joomla component, which actually overwrites some of your CiviCRM files – so do try it in a test environment before going live with it.
Do let me know if you try it. The intention is to now get proper ACL for Joomla implemented in a future Civi release, but this was a quick fix to cover some holes for now.
RogerCO
Comments
I am planning to try it in a test environments in the next week. I will let you know what my results are.
Is your code compatible with CiviCRM 3.0 beta?
The 'download it as a Joomla component' link is invalid. Any possibility this could be reposted or put in the svn repo?