The 5.7 branch of Magnolia reached End-of-Life on December 31, 2023, as specified in our End-of-life policy. This means the 5.7 branch is no longer maintained or supported. Please upgrade to the latest Magnolia release. By upgrading, you will get the latest release of Magnolia featuring significant improvements to the author and developer experience. For a successful upgrade, please consult our Magnolia 6.2 documentation. If you need help, please contact info@magnolia-cms.com.

Data is stored on the public context - synchronization between public nodes may be required

The record of consent for form-based data in the visitors workspace is created on the public Magnolia instance, never on the author instance. This is also true for referenced content, for instance in the contacts workspace.

You must synchronize the consent records stored if you use several public instances. The instances, or in our sample implementation at least the visitors, pendingContacts and contacts workspaces, must be clustered in order to share accounts between the different instances. Alternatively, implement observation-based synchronization to replicate visitor and contact data across instances.

  • No labels

6 Comments

  1. The includable will be used in the context of  DOCU-1556 - Getting issue details... STATUS

    Above is a first draft for an "info box" to be added to some of GDPR labelled pages. The text is copied from Public User Registration module and was adapted slightly.

    On the Visitors app page I will additionally add a note that for manual editing via Visitors app must be done on the public instance too (the data admin must login to admincentral of the public instance).

  2. The topic raises some questions. 

    Roman Kovařík: Is it correct that the workspace pendingContacts must be "synchronized" too?

  3. Nicolas Barbé - On the cloud, login to admincentral of a public space on the Live environment is possible, isn't it?

    Access to login on a public space actually is not only required for the Visitors app for GDPR but for managing PUR users too.

    Which leads me to the "idea" they we probably should provide such a link on the Package overview on the cockpit.

    Would you agree?

    1. >> On the cloud, login to admincentral of a public space on the Live environment is possible, isn't it?

      Yes possible, if I am correct it's the same configuration than on author, so potentially any editor can login. In practice it's only for Magnolia HD/SRE so we could restrict the access only to these people and remove the others, which will reduce the GDPR footprint for users on public to only Magnolia employees.

      >> Access to login on a public space actually is not only required for the Visitors app for GDPR but for managing PUR users too.

      We try to remove the needs to access the public instances and we have good reasons for that. If I understand this page correctly we would have to implement this observation to sync the data. Do you know if there is a reference implementation. It would be a good idea to have it packaged in the product.

  4. And a note to Antti HietalaChristopher ZimmermannNicolas Barbé and Roman Kovařík:

    If the synchronizing is too slow - the opt-in link (which was sent by email) to grant consent may fail, if the request sent by clicking the email-link goes to "the other public node". 
    (Besides we have sticky session on multi public installations.)

    Just saying ... :shrug: ... please correct me if I'm wrong!

    1. I am afraid sticky session won't always solve this problem, nothing guarantee that one clicks on the email link on the same device than the one he used to fill the form since the process is asynchronous.

      Plus sticky session is not really considered as good practice nowadays so I would not recommend that in the documentation to solve this problem (if it is confirmed).