CiviCRM Community Forums (archive)

v2.2.7 and earlier allow any site visitor to construct a url to see any profile information that is exposed on your site. If you have edit profiles this includes full editing of your data - hence front-end editing has been disallowed in 2.2.7 Joomla.

There is a further privacy issue, however, in that a casual visitor can view any contact information that is available in a profile.

If you do not need the public to see any CiviCRMdata - eg if you are running a members-only site, where only members can register and login and the public never see any pages with CiviCRM content - then here is a patch that at least stops the public being able to steal your contact data.

insert the following in civicrm.php in [joomlaroot]/components/com_civicrm around line 15 after the test for php v5
//check logged in - if not 403
$user = JFactory::getUser( );
if ( $user->get('guest')) {
JError::raiseError( 403, JText::_('Access Forbidden') );
return;
}
This will allow only logged in users to invoke civicrm and prevents the public from directly entering calls to civicrm component urls.

You could of course provide a nicer redirect than a bare 403

This is not a complete solution, as any logged in user can still view any contact's data on a profile by constructing the appropriate url - but in a member's only situation this might be less of an issue so long as all of you members have agreed with your data controller policy of sharing their information with other members (beware the Data Protection Act)

It looks like you could add logic in the civicrm_invoke() function to restrict editing (if you re-enable it as per v2.2.6 and earlier) to particular users or groups, but again users could bypass that by constructing the url directly.

I *think* this works ok - certainly the direct urls that were working on one of my sites now generate 403's, but logged in users' access to profile forms still works. I'd like to hear comments from others.

Hope this helps someone.
Cheers
RogerCO

Hi Brian,

What do you mean when you say "front-end editing has been disallowed in 2.2.7"?

See http://forum.civicrm.org/index.php/topic,9087.msg39136.html#msg39136 and links there-from. In 2.2.7 the only front end editing that is allowed is of your own details.

Looking a bit more into civicrm.php and thinking about the patch I made a year ago to allow Civi Groups to be used for access control I am becoming convinced that this Joomla front-end part of Civi needs some major work.

It would be nice to have various things set through menu and component parameters including access control using either/or/both Joomla levels (to be extended to full ACL in 1.6 I hear) and Civi Groups or Civi's own ACL. The first two are easy to do and don't require any changes to the Civi core.

It would also be good to have menu parameters for into and outro text above and below the CiviCRM profile display so that you could have different text for the same profile on different menu entries.

Most fundamentally this is the place to try and block people putting fancy query strings in to access profiles that they shouldn't be able to see. I envisage something like a list of Joomla user id's or user levels associated with each Civi gid (profile) used to block access to that gid.

At its simplest it could be a single component parameter containing a list of gid's which are publicly visible; a guest user trying a url with any other gid would be thrown out.

Perhaps then extend this to a three level test - public gid's, registered gid's and special gid's

This would require no change to the profile settings in core Civi CRM so could be implemented as a quick modification to the Joomla only files in the Joomla version.

I'm not familiar enough (at all) with how Drupal works to know if these changes would make any sense in the Drupal world, clearly there might be regression implications for any changes in files that are common to both J and D (ie the Civi Core)

RogerCO

Regarding the patch below... I think this would also prevent anonymous visitors from accessing CiviCRM contribution and event registration pages - so folks should consider this before implementing it.

...dave

Yes. I did say that, although not very explicitly. It will prevent public access to ANY CiviCRM page. Only ok if (like one of my sites) you are not using public contribution and event registration facilities (or any other facility you want people to see without logging in)

My preferred solution would be to have a Jooomla component parameter to define which gid's were allowed public access and check for that instead. But this works as a quick fix if you are not using public visible civi pages.

RogerCO

So a couple of thoughts and a few issues.

1. Thanx to roger's investigation, we uncovered some bugs and have filed issues and will fix them for 2.2.8 (CRM-4822, CRM-4821). Some patches for this are already in svn. We will post "diff" info as soon as possible for folks who want to patch their installs prior to 2.2.8 release next week (probably later today PDT).

2. Note that profiles by definition expose your database information to the world. In joomla due to lack of permissioning and ACL's all front end users have access to all profiles. Admins should be aware of this and should use the visibility settings wisely (User and User Admin visibility prevent folks from seeing information in the frontend for other folks in the listings page. CRM-4821 fixes the bug in the view page).

3. CRM-4822 address the issue of only displaying profile information for contacts in the group restricted by "limit listings to group" setting.

4. A fix in v2.2.7 (CRM-4688) prevents folks from editing profile entries that are not part of their contact record

5. In the medium term, integrating ACL's within joomla (http://civicrm.org/node/602) is a better more integrated approach and will get joomla version of civicrm on par with Drupal and Standalone with regard to permissioning. So would be great for the joomla community of users to step up and help make this happen.

6. Note that CiviCRM ACL's already have support for profiles and you can restrict which ACL groups can access which CiviCRM profiles (in Drupal and Standalone).

7. Frontend CiviCRM for joomla has limited / no permissioning. (only a few urls are exposed). Front end users have access to all the functionality in the exposed urls.

lobo

Thanks David and Donald, that sounds like it might cover most of the issues - but in doing so we are crippling Joomla use of CiviCRM.

I certainly hadn't realised that profiles effectively expose the information to the world - this, in my world at least, is most undesirable.

The statement "in Joomla due to lack of permissioning and ACLs all front-end users have access to all profiles" simply is not (or need not) be true. I think there is a fundamental misunderstanding of how Joomla is used going on here.

Firstly there is a simple ACL/permissioning system in Joomla based on public/registered/special with special further segmented into author/editor/publisher and additional backend admin levels. Components quite routinely use these categories to restrict access to functions. There are also components which significantly extend this or add their own permission groups - eg Community Builder and DocMan to name 2 at random.

Perhaps we should spool back to first principles and understand that in most (nearly all those I have dealt with) Joomla installs the backend access is only used for website admin. It is pretty unusual to give backend access to a user with an organisational function like looking after a document library or administering a contact database - most well formed components would expose the necessary routines for this organisational admin in the frontend, and reserve backend access for users needing to make structural changes.

So using CiviCRM in a Joomla environment I absolutely expect to be able to grant some users (perhaps the 'editors' Joomla category) the ability to edit some or all contact information, and other users (eg registered) the ability to edit some of their own information and view some others, and other users (eg public/guests) far more limited access - perhaps only to signup/contribute and register for events.

The situation you propose effectively prevents this from happening. The restriction to only allow editing of contacts other than the users own record, to the backend is just not viable. The profile field visibility as described by Dave is, I think, the current situation which is ok, as is the limit listings to Group profile setting with the addition that you now will not be able to trick it into showing other contacts not in the group.

I don't hear any proposal to address the most fundamental problem though which is the statement that profiles by definition expose your information to the world through the front end. In the world of concerns about privacy of personal information, data protection, and identity theft this is simply not acceptable and makes CiviCRM unusable on the Joomla front end.

As I understand it even with the proposed changes any public visitor would still be able to enter a url that referenced a valid profile and be able to see the listing and the contact details in that profile - this simply can not be allowed.

What is even worse is that this applies to any profile at all, even if you haven't actually exposed it in the front end through a menu entry.

The good news however is that this can very easily be fixed without making any changes to the core Civi functionality. The way Joomla works all access to a component on the front end is through its front-end part - in our case components/com_civicrm/civicrm.php and its associated views. This works by invoking the core Civi functions common to both Joomla and Drupal, but you could not easily call those core functions without going through the front-end component.

I don't think there is any absolute need at this stage to implement Civi ACL for Joomla - it would be nice to have, but the immediate problems need fixing first in the v2.x series.

So the solution it seems to me lies in civicrm.php and its associated view. By imposing access control there you can safely re-allow editing in the front end and let the Joomla site admin manage it through standard Joomla component and menu parameters (defined in the xml files).

Please think about this some more and don't continue to cripple the Joomla front end - it is quite unnecessary I think.

I am travelling for the next week but will be very happy to work on the Joomla specific bits to allow full functionality on the front end.

It may be that I have misunderstood some more fundamental problem with the core Civi stuff, in which case please explain your thinking some more.

I'd be especially interested to hear from other Joomla users whether they are a) using profiles to enable contacts to see and/or edit other contacts details, b) whether you knew that this meant that anyone could see those details, c) whether you think this is an issue - maybe it is just a UK concern about data protection and privacy, and d) whether you think the solution of not being able to use profiles with Joomla is acceptable. Also is my initial description of the difference between Joomla front-end and back-end access typical - do you routinely allow users back-end access to your sites?

Sorry for the very long post, but this seems to me a critical issue that I would like to help fix. If it is not of any concern to others then I'll just go away and hack out a workaround solution for myself - which will include needing to downgrade to v2.2.6 to get the editing facility back.

Cheers
RogerCO

a couple of clarifications:

1. I dont think we are crippling anything within Joomla, we are closing a few of the holes that expose more data than they really should across all CMS

2. CiviCRM's permissioning model on Joomla is primitive is fairly well known. Hence the blog post by Sarah to get ACL support for joomla. That should address a lot of your concerns.

3. If you think that there are simple patches to civicrm.php that will help improve things from a security/functionality patches in Joomla, please do submit your patches for discussion. We'd be happy to take a look at it and potentially integrate it with a 3.x release of CiviCRM

4. I find it a bit strange to hear statements like: "I absolutely expect to be able ...." or "...than the users own record, to the backend is just not viable". I think we have admitted that the lack of permissioning support in Joomla is a big deal. However as an open source project, we'd love it if the community steps up and helps the product meet "expectations" and make things "viable". The financial support for the permissioning support in joomla is not breaking any records unforunately

If you think it will help you and future users to make it more clear about the exposure of data within profiles, please do update the documentation and clarify things. we will review the changes, but your input and concerns on those documents would benefit a few people. yes, profiles are powerful, at the same time they can expose a fair amount of data if not configured properly and/or if bugs are present

lobo

lobo

Hi all,
Firstly apologies to Donald and the team, who I read may have been slightly miffed by my trenchant comments - no disrespect intended at all to the excellent core CiviCRM work, I'm merely interested in making the Joomla+Civi system more usable.  For me, at least, Civi is just one component of a system, and thus far it seems to be missing out on much of the potential of Joomla.

Anyway, whilst away I have been tinkering, and now have some mods which address most (not all) of my concerns and do allow secure (as far as I can tell, so almost certainly not completely secure) access to profile editing facilities on the front end.

Most of what I have done is changes in the joomla frontend component civicrm.php to allow access to profiles (whether menu'ed or direct linked) to be restricted by Joomla user group (guest-registered-author-editor-publisher-manager-admin-superadmin) and/or also by membership of Civi groups.

I did have to make a couple of changes in core files to unpick CRM4668 and replace with user level checks. The access levels are controlled by component and menu parameters, so there are also changes to the joomla xml files and the backend toolbar.

Question now is what is the best way to share these with others for further improvement and validation - please advise, or PM me if you want me to send the install package and more details of the changes.

Incidentally it looks from the complete 2.2.7 install set that there is work in progress to implement a proper MVC front-end component for Joomla - the view files exist but are as far as I can tell not used. This is clearly the right way to go and should be able to implement a front end that is independent of the CRM core, allowing use of the same styles as the rest of one's site.

I think I may have also uncovered a couple of other minor problems - how/where do I go about reporting these?

Regards
RogerCO

PS I don't think the CiviCRM team need do anything more than I have done regarding ACL for Joomla - there is a more sophisticated ACL system for Joomla coming "soon" (poss v1.6? - poss not till v2) and it would be better to wait and use or integrate with the native Joomla ACL rather than have a component which implements its own incompatible ACL system. Hence my preference right now for using the existing Joomla user groups and also making use of CiviCRM's ability to define groups of contacts and use those for access control on the front-end. But then my use of Civi is perhaps unusual in that I never (if possible) expose the backend to ordinary users. Getting front-end access to CiviMember information is my next priority.