Answers.Body: <p>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. </p>
  
  <p>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.</p>
  
  <p>If you want to build forms that communicate with CiviCRM on a separate server you might also want to take a look at CMRF.</p>
  
  <p>There is a <a href="https://civicrm.org/blog/jaapjansma/civiproxy-and-civimcrestface-sprint-in-bonn" rel="nofollow noreferrer">blogpost</a> on a recent sprint about this topic you might want to read.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-06T08:04:53.677Z
Answers.Text: 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.
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-03T08:18:08.023Z
Answers.LastActivityDate: 2017-08-03T08:18:08.023Z
Answers.UserDisplayName: ErikH - CiviCooP
Answers.Body: <p>I would not recommend your approach number 2, though in theory it sounds reasonable. Here's what I'd worry about going wrong:</p>
  
  <ol>
  <li><p>CiviCRM code might be unexpectedly accessing tables that you would not expect it to, generating white screens of death on your public facing site.</p></li>
  <li><p>The two different installs might be setting cached/calculated values differently due to the different urls that they think the install lives at.</p></li>
  </ol>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Update: based on your comment below, here's another way to get the outcome you want.</p>
  
  <ol>
  <li><p>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.</p></li>
  <li><p>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. </p></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T19:11:03.663Z
Answers.Text: 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
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-24T14:09:34.483Z
Answers.Text: Ah, the specifics of which fields/tables are sensitive is useful, see my update above for another solution.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T13:17:59.033Z
Answers.LastActivityDate: 2017-08-08T17:17:48.813Z
Answers.LastEditDate: 2017-08-08T17:17:48.813Z
Answers.UserDisplayName: Alan Dixon
Answers.Body: <p>I am not commenting on the concern you expressed but thought you might be interested in the <a href="https://civicrm.org/blog/jaapjansma/civiproxy-and-civimcrestface-sprint-in-bonn" rel="nofollow noreferrer">CiviProxy</a> Extension</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-02T04:33:20.880Z
Answers.Text: 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?
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-02T09:58:41.803Z
Answers.Text: 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
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-01T20:16:09.000Z
Answers.LastActivityDate: 2017-08-01T20:16:09.000Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>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 <a href="https://mariadb.com/resources/blog/protect-your-data-row-level-security-mariadb-100" rel="nofollow noreferrer">https://mariadb.com/resources/blog/protect-your-data-row-level-security-mariadb-100</a> some help?  But this is too custom code.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T19:07:29.780Z
Answers.Text: Yes, I'm thinking of just restricting custom fields
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-06T17:57:58.410Z
Answers.LastActivityDate: 2017-08-06T17:57:58.410Z
Answers.UserDisplayName: Kainuk - CiviCooP
Body: <p>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.</p>
  
  <p>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</p>
  
  <p>Two ideas that come to mind are:</p>
  
  <ol>
  <li><p>Do a remote integration - is that possible? - so that the public website pulls the data it needs via https or something</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>I am inclined towards 2. Can you see anything that might go wrong with it?</p>
  
Tags: <drupal><mysql><security><integration>
Title: Best way to integrate two sites with different security levels
ThreadText: # Best way to integrate two sites with different security levels
  
  (Asked by: username_0 on 2017-08-01)
  
  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?
  
  **Tags:** drupal, mysql, security, integration
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_1 on 2017-08-03. Score: 2
  
  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](https://civicrm.org/blog/jaapjansma/civiproxy-and-civimcrestface-sprint-in-bonn) on a recent sprint about this topic you might want to read.
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_2 on 2017-08-07. Score: 2
  
  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.
  
  > **Comments:**
  > **username_0**: 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  
  > **username_2**: Ah, the specifics of which fields/tables are sensitive is useful, see my update above for another solution.  
  
  ---
  
  ### Answer by username_3 on 2017-08-01. Score: 1
  
  I am not commenting on the concern you expressed but thought you might be interested in the [CiviProxy](https://civicrm.org/blog/jaapjansma/civiproxy-and-civimcrestface-sprint-in-bonn) Extension
  
  > **Comments:**
  > **username_0**: 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?  
  > **username_3**: 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  
  
  ---
  
  ### Answer by username_4 on 2017-08-06. Score: 1
  
  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.
  
  > **Comments:**
  > **username_0**: Yes, I'm thinking of just restricting custom fields  
  
  ---
  
  