Page MenuHomePhabricator

Add CiviProxy to crm repo, write configuration or code for filtering API calls
Closed, ResolvedPublic


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.

Event Timeline

Discussed on IRC:

  • Write custom CiviCRM API possibly within the existing wmf-civicrm extension to wrap CiviCRM Core API Contact calls. This will allow stricter API param rules.
  • Add civiproxy scripts to 'wikimedia/fundraising/crm'

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.

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 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.

Change 664901 had a related patch set uploaded (by Jgleeson; owner: Jgleeson):
[wikimedia/fundraising/crm/civiproxy@master] Clear out unused files and update Dockerfile

AndyRussG added a subscriber: AndyRussG.

Hi! I think we need to update the fields returned:

  • The country field in the data returned is the country name, but what we actually need is the country's ISO code.
  • I think we also need to return the donor's name, so that it can also be displayed on the form.


@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