volto-embed

GDPR-compliant external resource embedding components for Volto.

Right now it does several things:

• it replaces the Map default block with a variant that's data-protected
• it provides a component <PrivacyProtection> which can be used to wrap other components that wrap sensitive content
• it provides a function addPrivacyProtectionToSchema which adds the fields that are required to configure the "data protection" for any component wrapped in <PrivacyProtection>.

See src/Iframe/ViewIframe for details on how to implement.

Getting started

Try volto-embed with Docker

  git clone https://github.com/eea/volto-embed.git
  cd volto-embed
  make
  make start

Go to http://localhost:3000

make start now defaults to Volto 18. To run the same setup against Volto 17, use:

  VOLTO_VERSION=17 make
  VOLTO_VERSION=17 make start

Add volto-embed to your Volto project

1. Make sure you have a Plone backend up-and-running at http://localhost:8080/Plone

   docker compose up backend

2. Start Volto frontend

• If you already have a volto project, just update package.json:

  "dependencies": {
      "@eeacms/volto-embed": "*"
  }

  and volto.config.js:

  const addons = ['@eeacms/volto-embed'];

• If not, create one with Cookieplone, as recommended by the official Plone documentation for Volto 18+:

  uvx cookieplone project
  cd project-title

1. Install or update dependencies, then start the project:

   make install

   For a Cookieplone project, start the backend and frontend in separate terminals:

   make backend-start
   make frontend-start

   For a legacy Volto 17 project, install the package with yarn and restart the frontend as usual.

2. Go to http://localhost:3000

3. Happy editing!

Release

See RELEASE.md.

How to contribute

See DEVELOP.md.

Secret Scanning

This repository uses the Betterleaks GitHub Action to scan the current repository content on every push and pull request. The scan uses the rules in .gitleaks.toml and uploads a betterleaks-report artifact when a finding is detected.

If the optional SMTP secrets are configured, failed scans also send an email to the last commit committer. The workflow expects these repository or organization secrets:

• SMTP_URL
• SMTP_PORT (optional, defaults to 25)
• SMTP_EMAIL
• SMTP_PASSWORD (optional if the SMTP server does not require authentication)

Port 465 is sent with direct TLS; other ports use the default SMTP handshake. The email includes a short finding summary from the redacted Betterleaks report, including the redacted matched line from each finding.

There are three common outcomes:

1. Everything is OK. The Betterleaks / Scan for secrets check is green and no action is needed. Regular references to runtime values are OK, for example:

   const tokenFromCookie = req.universalCookies.get('auth_token');

2. A real secret was found. The check is red and the workflow log asks you to download the betterleaks-report artifact. Open the artifact from the GitHub Actions run and check the reported file, line and rule. Remove the committed value, move it to the proper secret store, and rotate it if it was exposed. A report entry looks like this:

   {
     "RuleID": "secret-literal-assignment",
     "File": "src/config.js",
     "StartLine": 12,
     "Secret": "[REDACTED]"
   }

3. The finding is a false positive. Keep the value only if it is clearly not sensitive, such as a test fixture, placeholder, or public example. Add betterleaks:allow on the same line and include a short explanation in the pull request.

   const testPassword = 'admin'; //betterleaks:allow

   password: "admin" #betterleaks:allow

Do not add betterleaks:allow to real credentials.

Copyright and license

The Initial Owner of the Original Code is European Environment Agency (EEA). All Rights Reserved.

See LICENSE.md for details.

Funding

European Environment Agency (EU)