It may be useful to also provide the personalized donor portal link here.

See also Google Doc from DR.

Later, DR would like to tag messages based on data from Civi. It looks like we can do this with Action Builder in ZD (call Civi API, tag based on response).

Noting here that Zendesk has a API for their public IP ranges, so we can configure CiviProxy to only allow from those: https://developer.zendesk.com/api-reference/ticketing/account-configuration/public_ips/

Just CC'ing @Ejegg on this one

@KHansen also requests that we also implement this for Wikipedia store ZD, not a huge priority, but we might as well do it at the same time as presumably this would be not much work. To confirm that ZD security for the store is equivalent to DR ZD security.

Added to the ZD store! marking this as closed!

Per @krobinson's request, we should scope out the security implications and use of CiviProxy in July with a view to providing a decision on feasibility ASAP, ideally launching this before September when email volumes increase.

@jgleeson can we check in on this with you before Sabbatical?

@Lars @AKanji-WMF I've reviewed this task, and I feel more comfortable with the risk profile. The proposed civiproxy endpoint takes an email address as input, so to exfiltrate anything, an attacker would already need to know donors' email addresses and be able to reach the endpoint from Zendesk's IPs. That means a meaningful breach would have had to occur already, and this endpoint wouldn't be the weak link.

One thought on Zendesk's IP allowlist: could we add a shared secret/token, held only by our instance, as an additional layer of protection? That would mean that even if Zendesk were breached, no other accounts could access this new API.

@jgleeson Yes, token known only to ZD (it is encrypted on their end and not accessible to anyone) and CiviProxy is definitely in the plans. That token will provide access only to this specific API action and nothing else and no other token will allow access to this action via CiviProxy.

Note to self to investigate the possibility of adding a rate limit setting to CiviProxy (or to an intermediate layer) to avoid someone potentially hammering this with a list of many emails in the worst case.

Further thoughts from our meeting today:

1. Separate the see donor details on the ticket functionality from the triage tickets as emails come in functionality, with the triage handled via api that returns the minimum viable amount of data to triage (possibly triage levels 1-5 or similar with 1 returned if no match and for low priority, so we don't expose lack of match) and showing data from CiviCRM on the ticket in an iframe.
2. For civiproxy: Rate limiting perhaps through nginx or directly in apache, @Dwisehaupt to investigate when required, also a second civiproxy instance just for this with separate config.
3. See {T428660}

Per discussion with DR, we can use 1-3 as giving levels here.

Showing donor data in an iframe split off to T433866: Show iframe with donor details in Zendesk.