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