This documentation relates to CiviCRM version 2.2. It's not maintained anymore.
Current version of documentation.

#usernavbar()

Joomla Front-End Profiles - view & edit control

Aller directement à la fin des métadonnées
Aller au début des métadonnées

This page refers to outdated version of CiviCRM. Check current version of documentation.


Documentation Search


CiviCRM 2.2 Documentation

Support and Participation

Developer Resources

CiviCRM modification Component com_jcivi_v2.2 for Joomla 1.5.14 and CiviCRM v2.2.8

Screenshots attached and component installation files attached.

Note: THIS IS NOT FULLY TESTED - PLEASE TEST IN YOUR OWN ENVIRONMENT BEFORE USING ON A LIVE SITE

Updated 13th August with v2.2 which allows smart groups to be used to restrict access to profiles

This package is a set of modifications for CiviCRM v2.2.8 in a Joomla 1.5.14 environment which allows control over who can access CiviCRM profiles through the Joomla frontend to view and edit contact details. It is packaged up as a Joomla component so that you can use the standard component installation routines - just install it as you would any other component and it will update the relevant CiviCRM files. There is a separate Undo component which will should reverse the changes, redtoring the v2.2.7 files

This is attempting to address two concerns:
Firstly the security and privacy issue partially addressed by CRM4668 between CiviCRM v2.2.6 and 2.2.7 which closed a loophole whereby any visitor could construct a URL query string which gave them access to any profile edit form. This left the privacy issue that if a profile view form had publicly viewable fields it could be accessed by any visitor irrespective of any restrictions placed on the Joomla menu link (public/registered/special) visibility.

Secondly this is providing additional functionality in that access to profiles (for search, listing, view or editing) can be restricted by full Joomla user group (guest/registered/author/editor/publisher/manager/admin) and also by CiviCRM group membership. This works irrespective of whether the link to the profile is through a Joomla menu link, or by directly constructing a URL query string.
The only links that are not validated are those using CiviCRM session variables in the query string - but in order to be using such a link you need to already have a validated session so this should not be a problem. Typically the 'Search' button on a profile search form uses such a link - but to have displayed the search form you would have to have been validated for that profile against your user level and groups. Please advise if you find a way of getting access to something you should not be able to see : roger@crosborne.co.uk

The access restrictions are all set up by the site administrator using Joomla menu and component parameters - these are defined in xml files. In this release you need to know the id numbers of any profiles or CiviCRM groups you wish to use as controls - Joomla 1.6 will introduce multi-select parameter lists so more admin friendly method of selection will be available.

 

The new standard Joomla component toolbar Parameters button is set to be visible
only to Super-Admins in the backend. The pop up form allows you to disable public
access to all CiviCRM functions and to restrict which profiles are visible to which
groups of users.
You can also set the minimum Joomla user level able to access any edit profile,
attempting to call a search listing for a profile you do not have sufficient rights to
edit results in the edit links being hidden, and attempting to access the edit form
direct simply gives the user an error message.


 

When creating menu entries for CiviCRM profiles you now have an additional
parameter to set the CiviCRM groups able to access this menu (NB this would not
stop direct access by constructing a URL query string knowing the profile ID)
You can also over-ride the component level parameters


Description of the changes:

There are changes to the Joomla com_civicrm frontend component (file civicrm.php in Components), and also changes to two files in the core CiviCRM package which control visibility of edit links and edit forms (files Edit.php and Listing.php in Administrator/Components/Ccom_civicrm/civicrm/CRM/Profile ). There are also new .xml files to define the parameters.

The component level parameters require a minor change to the admin file toolbar.civicrm.html.php to add the parameters button on the toolbar in the backend. Since some people give wider access to the backend, the Parameters button is only shown to the Super-Admin user (you could easily remove this restriction). No default values are set to avoid the Joomla quirk whereby if you have default values for a text box component parameter these defaults then get reinstated for a menu entry even if you have changed them at component level. (text box, unlike radio and selector types does not have a 'Use Global' default).

Menu parameters are defined in the relevant view xml files.

Part 1 - improving CRM4668 to use Joomla user groups to control access to editing. This involves changes to two core CiviCRM files. Firstly CRM/Profile/Selector/Listing.php around line 400 inserted code to check the user group and only show the edit link if allowed. Secondly CRM/Profile/Form/Edit.php around line 85 this now checks user level before actually displaying the edit form and redirects away if not authorised.

There is a quirk here that the CiviCRM code redirects to the CiviCRM $config->userFrameworkBaseURL, which is typically not a CiviCRM page, but the error message does not get displayed until the next time the user accesses a Civi page which can be confusing!

It should be quite easy to extend these edit validity checks to use restrictions by CiviCRM contact group.

Part 2 - setting up access control in general. There are several layers to this, almost all the changes are in the frontend control file JoomlaPath/Components/com_civicrm/civicrm.php. Most of the changes have been bundled into a new separate function check_joomla_permissions().

Before this there is a basic check introduced around line 22(all line numbers refer to the modified files) so that we can prevent ALL public access to CiviCRM functions. This happened to be a requirement for one of my sites so I put it here - it could be made more sophisticated allowing access to (say) profiles but not dashboard, or events but not profiles etc.

Next around line 90 we call the new check_joomla_permissions() function which returns true if the request in the $args is allowed or false with a message to be displayed if the request is barred.Around line 106 I have changed the style for the Civi 'no permission' message and also remove the synchronising of users and contacts as I prefer to handle this through the CiviAuthenticate plugin and CiviUser component.

check_joomla_permissions() is at the end of the file starting around line 175.

The first thing we do is check if we are a Super-Admin and if we are return true straight away - super-admins should be able to do anything.
In this version we are only policing access to profiles (line 196) - any other type of civicrm call is allowed through by default.

The next check is for guest users (line 203) - assuming we have allowed public access then we need to check the component parameter for Public Profiles to see if this profile id is listed. The parameter is a comma separated list of profile id numbers. 'any' can be used to alow any profile through, and an empty list will deny all.

Having dealt with guests we now have logged in users left who belong to a Joomla user group and may also belong to CiviCRM contact groups.

The switch at line 226 gets the appropriate component parameter for the Joomla group - note that these are specific, not cumulative, so an editor does not inherit the rights of an author and registered user. It could be made to inherit by removing the break; statements. They do all inherit the public rights though.

If you want to just use CiviRM groups to control access you will need to set all of the component access parameters to 'any'.

Having checked that the user is the right level to access this profile we now need to check whether she belongs to the right groups for this particular menu call. NB this check only applies if the profile is being called through a menu entry as only then will the menu parameter be set for the code to check against. This means that this check is NOT secure - a user could construct a url for a profile for which his Joomla user level was enabled but which his Civi Group membership was not valid and still gain access to the profile - this would apply to edit as well as view profiles. So in the lowest case if you had a profile which was enabled for registered user view but which you wished to restrict to a subset through a Civi group, then a registered user who was not a member of the group could still access the profile directly - it becomes a question of how far you trust your members. A solution should be possible either through work inside CiviCRM or with the new coming Joomla ACL system.

Line 260 checks whether we are restricting by Civi group. Only a single group can be selected in the parameter for each menu entry, but smart groups can be included.

So that is it - to use this the site admin needs to set up the relevant parameters both at component level (the button in the toolbar in the backend) and at menu level (when creating menu entries)
A final point - if you wish to use Joomla SEF URLs to mask the details of query strings from the casual user then a useful way of doing this for direct links (eg in the body of an article) for which you don't have a menu option, is to set up a hidden menu which has the link you want (either as a component type or even as a simple url) and set an alias there. Then you can use the SEF form in your direct link. Simply create a menu in the normal way and set the module menu assignment to none.

Many possible tweaks for particular situations - some people might want more flexible error messaging. Currently it is using the message css class in the Joomla template css - there is a nice Joomla system call to show different box styles depending on warning/info/ message type etc

Étiquette
  • Aucun