We have a civi install that contains some sensitive data. We also have a public facing website. We would like to integrate them so that you can sign up for events, give donations etc on the website. The first though was to have a single site, but we would rather not have sensitive data sitting behind a public site.

EDIT: Also the less custom code the better. A solution that depends on crafting our own forms and interactions between sites is probably going to take too long both to develop and to fix when it goes wrong

Two ideas that come to mind are:

  1. Do a remote integration - is that possible? - so that the public website pulls the data it needs via https or something

  2. Have them on same server but different directories (and different Linux users) but both civi installs point to the same database, but as different mysql users. So the website cannot access certain tables.

I am inclined towards 2. Can you see anything that might go wrong with it?

4 Answers 4


Naomi, CiviProxy at the moment deals with mailings and stuff, and whitelists API calls. So if you would want to create a donation page on your public website, you would probably use the API to send data to CiviCRM.

When using CiviProxy your public website would send the API request to CiviProxy. CiviProxy would then check if the API request is allowed, and if so pass it on to CiviCRM.

If you want to build forms that communicate with CiviCRM on a separate server you might also want to take a look at CMRF.

There is a blogpost on a recent sprint about this topic you might want to read.

  • Thanks, but what I didn't say in my question (edited now) is that we don't want (or have time to write) a lot of custom code. So I think the database user method is still winning, because we can have normal Drupal views and blocks rather than writing code to communicate between sites.
    – naomi
    Aug 6, 2017 at 8:04

I would not recommend your approach number 2, though in theory it sounds reasonable. Here's what I'd worry about going wrong:

  1. CiviCRM code might be unexpectedly accessing tables that you would not expect it to, generating white screens of death on your public facing site.

  2. The two different installs might be setting cached/calculated values differently due to the different urls that they think the install lives at.

But perhaps most signficantly, the tables that you'd need to access publicly are probably the ones that are most sensitive, e.g. the contacts tables and the payment processor table.

So best to spend your energy/money/time securing your main civi install, unless you want to do the custom code things offered in the other answers.

Update: based on your comment below, here's another way to get the outcome you want.

  1. Create two separate mysql users as in your option 2 (a "secure" and an "insecure" user), and remove the access to the custom tables for the insecure user.

  2. Provide two separate 'pathways' into your install, based on authentication. For example, you could edit the civicrm config file to set the CIVICRM_DSN differently depending on the ip of the connecting user. If you're using Drupal, I think you might be able to set it differently depending on the permissions of the logged in user.

  • Although donor information is sensitive and we will take all reasonable measures to secure both sites, what we are most concerned about is client and casework data. Most of this is in custom fields, which are separate tables. However your point about cached (also relates to configuration) values is very pertinent and I had not thought of it. Thanks
    – naomi
    Aug 7, 2017 at 19:11
  • Ah, the specifics of which fields/tables are sensitive is useful, see my update above for another solution.
    – Alan Dixon
    Aug 24, 2017 at 14:09

I am not commenting on the concern you expressed but thought you might be interested in the CiviProxy Extension

  • Thanks. So this is a way of doing option 1, if I understand correctly? I'm concerned about how developed it is though. They mention donations for example but when you read the docs it seems to say that only mailing list signups are actually implemented. Do you know if we would be able to display event listings and submit donations? And how complex a task that would be?
    – naomi
    Aug 2, 2017 at 4:33
  • Really can't comment sorry. I only read about it an hour or so before seeing your question, so thought I would join some dots. sorry if it isn't that helpful to you at this point
    – petednz - fuzion
    Aug 2, 2017 at 9:58

Just elaborating on option 2. Where is the sensitive data located? Do you use a set of custom fields? This causes the data to be stored in a separate table, and you can use this strategy. If the data is stored in the standard CiviCRM tables, you must find a MySQL-native mechanism to protect the private data. Maybe the blog offers https://mariadb.com/resources/blog/protect-your-data-row-level-security-mariadb-100 some help? But this is too custom code.

  • Yes, I'm thinking of just restricting custom fields
    – naomi
    Aug 7, 2017 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.