Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.7.9
-
Fix Version/s: 4.7.14
-
Component/s: CiviCRM Profile, WordPress Integration
-
Security Level: Security - Published
-
Labels:
-
Versioning Impact:Major (incompatible API change)
-
Documentation Required?:None
-
Funding Source:Contributed Code
Description
the profile edit form does a series of permission checks during the preProcess routine. in particular, if an ID is passed via the URL, indicating the profile edit form should be loaded with a different contact than the logged in user (or as an anonymous user), it runs through some checks to see if the form should be loaded via checksum authentication or other methods.
dating back several years, a couple issues were filed addressing a few concerns impacting Joomla. in particular, the problems appeared to stem from the fact that Joomla creates a strict separation between front and backend interfaces, and how Civi handles that is different from Drupal (and now WP).
those Joomla-specific changes were made by conditioning on the config property "userFrameworkFrontend" – which I don't believe is used in Drupal at all, and so this was a meaningful distinction. however, we do use that in WP, and as a result, the full set of permission checks are not getting accessed when attempting to view a profile in WP (it shortcircuits and only validates access if a checksum is passed).
I ran into this when using this extension:
https://civicrm.org/extensions/relationship-permissions-acls
it manifests because the aclWhereClause hook is never hit when attempting to access a profile edit form you should be able to access. the fix is to limit the existing condition that shortcircuits the full range of permission checks to only Joomla.
Attachments
Issue Links
- links to