Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix permission check on Contribution form, clarify underlying functions #27013

Merged
merged 2 commits into from
Aug 14, 2023

Conversation

eileenmcnaughton
Copy link
Contributor

@eileenmcnaughton eileenmcnaughton commented Aug 6, 2023

Overview

This is a reviewer response to #22951

In that PR it seeks to set UserID to something derived from a function that is doing a lot of work. I dug into that function which someone (ahem) wrote many years ago and teased out some of the underlying chunks & cleaned up the variable names for clarity along with a doc block cleanup.

I decided that rather than set _userID in contributionBase we should remove it (it is only referred to in 4 places) and call the more specific function at each usage.

Otherwise we change the meaning of userID that is used somewhat differently later.

Also I rather prefer functions that will perform the same whenever called over relying on a variable having been set correctly the first time

Before

It is not possible to load from the mid on the contribution page if checksum authentication has been used

After

If the checksum user can view a membership it can be loaded

Technical Details

->_userID only used in a test with these changes

image

Comments

@civibot
Copy link

civibot bot commented Aug 6, 2023

Thank you for contributing to CiviCRM! ❤️ We will need to test and review the PR. 👷

Introduction for new contributors
  • If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
  • A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
  • A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
  • If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
  • Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
  • A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
  • To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
  • For more information about contributing, see CONTRIBUTING.md.
Quick links for reviewers

@civibot civibot bot added the master label Aug 6, 2023
CRM_Core_Resources::singleton()->addVars('coreForm', ['contact_id' => (int) $tempID]);
CRM_Core_Resources::singleton()->addVars('coreForm', ['checksum' => $userChecksum]);
return $tempID;
if ($requestedContactID === $this->getAuthenticatedContactID()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that $this->getAuthenticatedContactID() is always an int so will not match NULL here

elseif ($tempID && CRM_Contact_BAO_Contact_Permission::allow($tempID)) {
CRM_Core_Resources::singleton()->addVars('coreForm', ['contact_id' => (int) $tempID]);
return $tempID;
if ($requestedContactID && CRM_Contact_BAO_Contact_Permission::allow($requestedContactID)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this only allows permissioning another user by the logged in user. I wondered about that - but since really only the cid in the url can be check-sum authenticated there hypothetical of a checksum user needed permissioned access to another user does not apply

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't there always the "contribute as someone else" on front end forms at some point?

Copy link
Contributor Author

@eileenmcnaughton eileenmcnaughton Aug 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seamuslee001 yep - but you can combine that with logged in user permissions, but not checksum authentication permissions from my read on the before code (presumably cos cid has to be in the url to be validated with checksum)

@mlutfy
Copy link
Member

mlutfy commented Aug 11, 2023

I did a fair amount of testing and it seems to work well.

  • Tested renewing "on behalf of", as per initial use-case
  • Tested to make sure that "not you? then cid=0" still works

Also had a look at the code, and it's definitely not fun code, but I definitely appreciate having a clear getAuthenticatedContactID function, because previously every form kind of had to do their own check, and I'm sure I've done it wrong half the time.

Thank you @eileenmcnaughton !

cc @mattwire this might interest you

@mlutfy mlutfy added the merge ready PR will be merged after a few days if there are no objections label Aug 11, 2023
@mlutfy
Copy link
Member

mlutfy commented Aug 12, 2023

jenkins, test this please

@mlutfy mlutfy force-pushed the auth branch 3 times, most recently from 6f76735 to bdfb2fa Compare August 12, 2023 00:31
@mlutfy
Copy link
Member

mlutfy commented Aug 12, 2023

I had done a bit of a mess while trying to solve the conflict because of #27053, but it should be fine now.

Diff of the PR, before/after:

$ diff /tmp/membership.patch /tmp/membership3.patch 
1c1
< From 3d960a758ac55c2153e7d37ba9e31613e2069060 Mon Sep 17 00:00:00 2001
---
> From bdfb2fae6f26331f59b63b479f74db9403441197 Mon Sep 17 00:00:00 2001
27c27
< index 36422a48f3b..396f19579d5 100644
---
> index 82767a072cd..b423a4b41ca 100644
61c61
<                $inheritedRelTypes = implode(CRM_Utils_Array::explodePadded($membershipType->relationship_type_id), ',');
---
>                $inheritedRelTypes = implode(',', CRM_Utils_Array::explodePadded($membershipType->relationship_type_id));

@eileenmcnaughton
Copy link
Contributor Author

@mlutfy I haven't done it at this point - but I have started to mark functions which feel 'settled & consistent' on forms with @api to indicate they are supported for extension usage. Perhaps you have just made the case for getAuthenticatedContactID to be marked as such

@mlutfy
Copy link
Member

mlutfy commented Aug 12, 2023

@eileenmcnaughton oh, I like that idea! Can you do it as part of this PR, or want me to do it?

This is a reviewer response to civicrm#22951

In that PR it seeks to set UserID to something derived from a function that is doing
a lot of work. I dug into that function which someone (ahem) wrote many years ago
and teased out some of the underlying chunks & cleaned up the variable names for clarity
along with a doc block cleanup.

I decided that rather than set _userID in contributionBase we should remove it
(it is only referred to in 4 places) and call the more specific function at each usage.

Otherwise we change the meaning of userID that is used somewhat differently later.

Also I rather prefer functions that will perform the same whenever called over relying
on a variable having been set correctly the first time
@eileenmcnaughton
Copy link
Contributor Author

@mlutfy - Ok I've pushed in a test + comment

@eileenmcnaughton
Copy link
Contributor Author

@eileenmcnaughton
Copy link
Contributor Author

@mlutfy mlutfy merged commit 44efaf5 into civicrm:master Aug 14, 2023
@mlutfy
Copy link
Member

mlutfy commented Aug 14, 2023

@eileenmcnaughton you rock - thank you!

@eileenmcnaughton eileenmcnaughton deleted the auth branch August 14, 2023 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
master merge ready PR will be merged after a few days if there are no objections
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants