We will want to filter API calls to only allow contact.get, always including contact ID and time-limited hash, and only returning opt in and opt out fields. If that's not possible in configuration, write a little custom API call to wrap contact.get with those filters and configure civiproxy to only allow this custom call.
https://docs.civicrm.org/civiproxy/en/latest/
https://github.com/systopia/CiviProxy
https://github.com/jackgleeson/CiviProxy
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T125272 Epic: Create Preference Center for donors to manage email subscription preferences | |||
| Resolved | None | T268495 Add CiviProxy to crm repo, write configuration or code for filtering API calls | |||
| Resolved | jgleeson | T270384 Dockerize CiviProxy | |||
| Restricted Task |
Discussed on IRC:
I've forked the main project and pushed up a patch which gets us CiviProxy running locally.
@Eileenmcnaughton to make stepping through the internals easier I added xDebug to the build in the latest commit.
@Eileenmcnaughton @Ejegg we might need to adapt CiviProxy to send a client certificate along with requests right? as the current production frontend requires them.
Update:
The answer to this is no. Instead, we're gonna open allow traffic to production CiviCRM from the IP of the box CiviProxy runs on with no client certificate checks.
What do we do next on civiproxy?
a) I've updated the api such that it now returns the 4 fields for our prototype when fed a contact hash b) I think we want to switch from hash to checksum - I will investigate that c) I guess we need to finalise with Jeff and Dallas where civiproxy will sit. It seems it need to be it's own webroot / url that just serves up the contents of one folder - as such it makes sense to me that it is it's own wmf repo (we can rip out the irrelevant stuff) - we need to check with Jeff & Dallas how we would trial d) we need to confirm / set up a repo for config for civiproxy
So I think with b & c & d done that would be the requirements for https://phabricator.wikimedia.org/T268495 would be met. I don't know how we finalise the civiproxy docker work you have done but it is probably not in the critical path for T268495 & maybe should be it's own phab. The work you've done so far allowed me to test it - which is what I got stuck on last time so it's important to do that finalisation but just looking specifically at that ticket.
I added a subtask to capture the CiviProxy docker work here T270384
I'll look at upstreaming that too.
Repo has been requested here https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests
Change 664901 had a related patch set uploaded (by Jgleeson; owner: Jgleeson):
[wikimedia/fundraising/crm/civiproxy@master] Clear out unused files and update Dockerfile
Hi! I think we need to update the fields returned:
Thanks!!
@AndyRussG I can fix the country field to iso code pretty easily
Regarding name - that is a scope change in terms of our exposure (in terms of what could be retrieved by hammering the url with brute generated or perhaps leaked contact id / hash combos). It's a technically easy change but I think at this stage it is a spec change to the agreed security scope (although I could be out of date)
Change 664901 merged by Eileen:
[wikimedia/fundraising/crm/civiproxy@master] Clear out unused files and update Dockerfile
Change 756023 had a related patch set uploaded (by Jgleeson; author: Jgleeson):
[wikimedia/fundraising/crm/civicrm@master] Re-add settings_location.php
Change 756023 merged by jenkins-bot:
[wikimedia/fundraising/crm/civicrm@master] Re-add settings_location.php
Change 763346 had a related patch set uploaded (by Eileen; author: Jgleeson):
[wikimedia/fundraising/crm/civicrm@master] Re-add settings_location.php