Domaine personnalisé & HTTPS

Domaine personnalisé & HTTPS

Une nouvelle installation répond sur http://localhost. Ce guide le déplace vers votre propre domaine via HTTPS — par exemple https://consent.example.com.

Faites cela avant d'ajouter des sites. Chaque script de consentement généré par Conzent a votre domaine intégré. Changer le domaine plus tard fonctionne, mais vous devez régénérer les scripts (étape 5) et mettre à jour le snippet d'intégration sur chaque site web qui les utilise déjà (étape 6).

1. Pointez le DNS vers votre serveur

Créez un enregistrement A pour le nom d'hôte que vous souhaitez, pointant vers l'IP publique de votre serveur :

consent.example.com.   A   203.0.113.10

Confirmez qu'il se résout avec dig +short consent.example.com avant de continuer. Un sous-domaine d'un domaine que vous possédez déjà — consent., cmp., privacy. — est le choix habituel.

2. Définir APP_URL

APP_URL est la seule source de vérité pour chaque URL absolue produite par Conzent : points de terminaison des scripts de consentement, le snippet d'intégration affiché dans le tableau de bord, les liens de réinitialisation de mot de passe et les rappels OAuth.

Modifiez .env dans votre répertoire d'installation :

APP_URL=https://consent.example.com

Utilisez l'URL publique exacte, avec le schéma et sans barre oblique finale. Si vous terminez TLS — et vous devriez — cela signifie https://, même si le conteneur lui-même parle encore HTTP en interne. Définir https:// change également le cookie "se souvenir de moi" en Secure, afin qu'il ne soit jamais envoyé via HTTP en clair.

Les nouvelles installations peuvent effectuer les étapes 1 et 2 en une seule fois :

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

3. Terminer TLS

Le conteneur nginx intégré sert HTTP en clair sur ${APP_PORT:-80}. Il n'obtient ni ne sert de certificats.

Option A — Caddy devant. Caddy récupère et renouvelle automatiquement les certificats Let's Encrypt. Libérez le port 80 en définissant APP_PORT=8080 dans .env, puis créez docker-compose.override.yml :

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:

Avec docker/caddy/Caddyfile :

consent.example.com {
    reverse_proxy nginx:80
}

Exécutez docker compose up -d. Caddy délivre le certificat lors de la première demande.

Option B — un nginx ou Apache existant. Définissez APP_PORT=8080 dans .env, puis proxy vers celui-ci :

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 est important au-delà de la propreté : Conzent enregistre l'IP du visiteur sur chaque entrée de journal de consentement et l'utilise pour le ciblage géographique. Sans l'en-tête, chaque consentement est attribué à votre proxy.

Option C — Cloudflare. Proxy le record et définissez le mode SSL/TLS sur Complet. Gardez TLS d'origine activé ; "Flexible" laisse le saut entre Cloudflare et votre serveur non chiffré. Définissez CLOUDFLARE_ZONE_ID et CLOUDFLARE_API_TOKEN dans .env pour que Conzent purge automatiquement le cache de bord lorsque les scripts changent.

Placez les modifications de pile dans docker-compose.override.yml, jamais dans docker-compose.yml — les mises à jour réinitialisent les fichiers suivis, et le fichier d'override est laissé intact.

4. Redémarrez et confirmez

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

Chargez https://consent.example.com. Vous devriez obtenir la page de connexion via un certificat valide.

5. Régénérez les scripts de consentement

C'est l'étape qu'il est facile de manquer et qui produit les symptômes les plus étranges si vous le faites.

Le script de chaque site se trouve à public/sites_data/{site_key}/script.js et contient des URLs absolues construites à partir de APP_URL au moment de la génération — le point de terminaison API auquel il envoie le consentement, le CSS qu'il récupère, les chemins des logos. Changer APP_URL ne réécrit pas les scripts qui existent déjà. Jusqu'à ce que vous régénériez, les bannières sur les sites de vos clients continuent d'appeler l'ancien hôte : le consentement est enregistré contre la mauvaise origine, ou échoue complètement une fois que l'ancienne adresse cesse de répondre.

docker compose exec app php bin/oci scripts:regenerate

6. Mettez à jour le snippet d'intégration sur vos sites web

Le snippet affiché dans le tableau de bord pointe maintenant vers le nouveau domaine :

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

Si vous déplacez une installation en direct, gardez l'ancien nom d'hôte résolvant et proxy vers le nouveau jusqu'à ce que vous ayez échangé chaque intégration. Le chargeur est le point d'entrée pour toute la bannière — un src cassé signifie pas de bannière de consentement du tout.

7. Vérifiez de bout en bout

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

Ensuite, chargez une page qui intègre la bannière, acceptez le consentement et confirmez que l'entrée apparaît sous Journaux de consentement. Ce seul aller-retour teste ensemble DNS, TLS, le chargeur, le script généré et le chemin API.

Dépannage

La référence complète se trouve avec le code : docs/custom-domain.md sur GitHub.