-
-
Notifications
You must be signed in to change notification settings - Fork 827
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
Conversation
Thank you for contributing to CiviCRM! ❤️ We will need to test and review the PR. 👷 Introduction for new contributors
Quick links for reviewers |
CRM_Core_Resources::singleton()->addVars('coreForm', ['contact_id' => (int) $tempID]); | ||
CRM_Core_Resources::singleton()->addVars('coreForm', ['checksum' => $userChecksum]); | ||
return $tempID; | ||
if ($requestedContactID === $this->getAuthenticatedContactID()) { |
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
I did a fair amount of testing and it seems to work well.
Also had a look at the code, and it's definitely not fun code, but I definitely appreciate having a clear Thank you @eileenmcnaughton ! cc @mattwire this might interest you |
jenkins, test this please |
6f76735
to
bdfb2fa
Compare
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:
|
@mlutfy I haven't done it at this point - but I have started to mark functions which feel 'settled & consistent' on forms with |
@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
@mlutfy - Ok I've pushed in a test + comment |
I also added a note https://docs.civicrm.org/dev/en/latest/hooks/#pitfalls-of-hooks |
@eileenmcnaughton you rock - thank you! |
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
Comments