Eigen domein & HTTPS

Wijs je eigen domein toe aan een zelfgehoste Conzent OCI-installatie, beëindig TLS en genereer toestemmingsscripts opnieuw zodat elke site laadt vanaf de nieuwe host.

Eigen domein & HTTPS

Een nieuwe installatie reageert op http://localhost. Deze handleiding verplaatst hem naar je eigen domein via HTTPS — bijvoorbeeld https://consent.example.com.

Doe dit voordat je sites toevoegt. Elk toestemmingsscript dat Conzent genereert heeft je domein erin verwerkt. Het domein achteraf wijzigen werkt, maar je moet de scripts opnieuw genereren (stap 5) en het insluitfragment bijwerken op elke website die ze al gebruikt (stap 6).

1. Wijs DNS naar je server

Maak een A-record aan voor de hostnaam die je wilt, gericht op het publieke IP-adres van je server:

consent.example.com.   A   203.0.113.10

Bevestig dat het wordt opgelost met dig +short consent.example.com voordat je verdergaat. Een subdomein van een domein dat je al bezit — consent., cmp., privacy. — is de gebruikelijke keuze.

2. Stel APP_URL in

APP_URL is de enige bron van waarheid voor elke absolute URL die Conzent produceert: eindpunten voor toestemmingsscripts, het insluitfragment in het dashboard, links voor het opnieuw instellen van wachtwoorden en OAuth-callbacks.

Bewerk .env in je installatiemap:

APP_URL=https://consent.example.com

Gebruik de exacte publieke URL, met het schema en zonder afsluitende schuine streep. Als je TLS beëindigt — en dat zou je moeten — betekent dat https://, ook al spreekt de container intern nog gewone HTTP. Het instellen van https:// schakelt ook de "onthoud mij"-cookie over naar Secure, zodat deze nooit via gewone HTTP wordt verzonden.

Nieuwe installaties kunnen stap 1 en 2 in één keer uitvoeren:

curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

3. Beëindig TLS

De meegeleverde nginx-container serveert gewone HTTP op ${APP_PORT:-80}. Hij verkrijgt geen certificaten en serveert ze ook niet.

Optie A — Caddy ervoor. Caddy haalt automatisch Let's Encrypt-certificaten op en vernieuwt ze. Maak poort 80 vrij door APP_PORT=8080 in te stellen in .env, en maak daarna docker-compose.override.yml aan:

services:
  caddy:
    image: caddy:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./docker/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config
    depends_on:
      - nginx
    restart: unless-stopped

volumes:
  caddy-data:
  caddy-config:

Met docker/caddy/Caddyfile:

consent.example.com {
    reverse_proxy nginx:80
}

Voer docker compose up -d uit. Caddy geeft het certificaat uit bij het eerste verzoek.

Optie B — een bestaande nginx of Apache. Stel APP_PORT=8080 in in .env, en proxy er dan naartoe:

server {
    listen 443 ssl http2;
    server_name consent.example.com;

    ssl_certificate     /etc/letsencrypt/live/consent.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/consent.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

X-Forwarded-For is meer dan een kwestie van netheid: Conzent legt het IP-adres van de bezoeker vast bij elke toestemmingslogboekvermelding en gebruikt het voor geo-targeting. Zonder de header wordt elke toestemming toegeschreven aan je proxy.

Optie C — Cloudflare. Proxy het record en stel de SSL/TLS-modus in op Full. Houd origin-TLS aan; "Flexible" laat de verbinding tussen Cloudflare en je server onversleuteld. Stel CLOUDFLARE_ZONE_ID en CLOUDFLARE_API_TOKEN in in .env zodat Conzent de edge-cache automatisch leegmaakt wanneer scripts wijzigen.

Zet stack-wijzigingen in docker-compose.override.yml, nooit in docker-compose.yml — updates stellen bijgehouden bestanden opnieuw in, en het override-bestand wordt met rust gelaten.

4. Opnieuw starten en bevestigen

docker compose up -d
docker compose exec app php bin/oci health

Laad https://consent.example.com. Je zou de inlogpagina moeten zien via een geldig certificaat.

5. Toestemmingsscripts opnieuw genereren

Dit is de stap die gemakkelijk over het hoofd wordt gezien en de vreemdste symptomen veroorzaakt als dat gebeurt.

Het script van elke site staat op public/sites_data/{site_key}/script.js en bevat absolute URL's gebouwd op basis van APP_URL ten tijde van generatie — het API-eindpunt waarnaartoe toestemming wordt gepost, de CSS die wordt opgehaald, de logopaden. Het wijzigen van APP_URL herschrijft geen scripts die al bestaan. Totdat je opnieuw genereert, blijven banners op de sites van je klanten de oude host aanroepen: toestemming wordt geregistreerd bij de verkeerde oorsprong, of mislukt volledig zodra het oude adres niet meer reageert.

docker compose exec app php bin/oci scripts:regenerate

6. Werk het insluitfragment bij op je websites

Het fragment dat in het dashboard wordt getoond verwijst nu naar het nieuwe domein:

<script async src="https://consent.example.com/c/consent.js" data-key="YOUR_SITE_KEY"></script>

Als je een live installatie verplaatst, zorg er dan voor dat de oude hostnaam blijft werken en doorverwijst naar de nieuwe, totdat je elk insluitfragment hebt vervangen. De loader is het toegangspunt voor de hele banner — een kapotte src betekent helemaal geen toestemmingsbanner.

7. Controleer van begin tot eind

curl -sSI https://consent.example.com/c/consent.js | head -1
curl -s https://consent.example.com/sites_data/YOUR_SITE_KEY/version.json

Laad daarna een pagina die de banner insluit, accepteer de toestemming en bevestig dat de vermelding verschijnt onder Toestemmingslogboeken. Die enkele rondreis test DNS, TLS, de loader, het gegenereerde script en het API-pad samen.

Problemen oplossen

Symptoom Oorzaak
Banner verschijnt niet Het insluitfragment verwijst nog naar het oude domein, of scripts zijn nooit opnieuw gegenereerd
Toestemmingslogboeken gestopt na de verplaatsing Het gegenereerde script post naar het oude API-pad — voer scripts:regenerate uit
Elk toestemmingslogboek toont hetzelfde IP De proxy stuurt X-Forwarded-For niet door
Reset-e-mails linken naar localhost APP_URL niet bijgewerkt, of containers niet opnieuw gestart na het bewerken van .env
Gemengde-inhoud-waarschuwingen APP_URL is http:// terwijl de site via HTTPS wordt geserveerd
Certificaat wordt nooit uitgegeven Poort 80 wordt nog door een andere service bezet gehouden
Compose-bewerkingen verdwenen Een update heeft bijgehouden bestanden teruggezet — verplaats ze naar docker-compose.override.yml

De volledige referentie staat bij de code: docs/custom-domain.md op GitHub.

Terug naar documentatie