Dominio personalizzato e HTTPS

Dominio personalizzato & HTTPS

Una nuova installazione risponde su http://localhost. Questa guida la sposta sul tuo dominio tramite HTTPS — ad esempio https://consent.example.com.

Esegui questa operazione prima di aggiungere siti. Ogni script di consenso generato da Conzent contiene il tuo dominio al suo interno. Cambiare il dominio in seguito è possibile, ma dovrai rigenerare gli script (passaggio 5) e aggiornare lo snippet di incorporamento su ogni sito web che li utilizza già (passaggio 6).

1. Punta il DNS al tuo server

Crea un record A per il nome host desiderato, puntando all'IP pubblico del tuo server:

consent.example.com.   A   203.0.113.10

Verifica che si risolva con dig +short consent.example.com prima di continuare. Un sottodominio di un dominio che già possiedi — consent., cmp., privacy. — è la scelta più comune.

2. Imposta APP_URL

APP_URL è l'unica fonte di verità per ogni URL assoluto prodotto da Conzent: endpoint degli script di consenso, snippet di incorporamento mostrato nella dashboard, link di reimpostazione password e callback OAuth.

Modifica .env nella directory di installazione:

APP_URL=https://consent.example.com

Usa l'URL pubblico esatto, con lo schema e senza barra finale. Se stai terminando TLS — e dovresti — significa https://, anche se il container stesso continua a comunicare in HTTP semplice internamente. Impostare https:// imposta anche il cookie "ricordami" come Secure, in modo che non venga mai inviato tramite HTTP semplice.

Le nuove installazioni possono eseguire i passaggi 1 e 2 in un'unica operazione:

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

3. Termina TLS

Il container nginx incluso serve HTTP semplice su ${APP_PORT:-80}. Non ottiene né serve certificati.

Opzione A — Caddy davanti. Caddy recupera e rinnova automaticamente i certificati Let's Encrypt. Libera la porta 80 impostando APP_PORT=8080 in .env, quindi crea 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:

Con docker/caddy/Caddyfile:

consent.example.com {
    reverse_proxy nginx:80
}

Esegui docker compose up -d. Caddy emette il certificato alla prima richiesta.

Opzione B — un nginx o Apache esistente. Imposta APP_PORT=8080 in .env, quindi fai il proxy verso di esso:

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 ha importanza al di là dell'ordine: Conzent registra l'IP del visitatore per ogni voce del log di consenso e lo utilizza per il geo-targeting. Senza l'header, ogni consenso viene attribuito al tuo proxy.

Opzione C — Cloudflare. Metti il record in proxy e imposta la modalità SSL/TLS su Full. Mantieni TLS sull'origine attivo; "Flexible" lascia il tratto tra Cloudflare e il tuo server non cifrato. Imposta CLOUDFLARE_ZONE_ID e CLOUDFLARE_API_TOKEN in .env affinché Conzent purghi automaticamente la cache edge quando gli script cambiano.

Metti le modifiche allo stack in docker-compose.override.yml, mai in docker-compose.yml — gli aggiornamenti ripristinano i file tracciati, mentre il file di override viene lasciato intatto.

4. Riavvia e conferma

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

Carica https://consent.example.com. Dovresti ottenere la pagina di accesso tramite un certificato valido.

5. Rigenera gli script di consenso

Questo è il passaggio che è facile tralasciare e che produce i sintomi più strani se lo fai.

Lo script di ogni sito si trova in public/sites_data/{site_key}/script.js e contiene URL assoluti costruiti da APP_URL al momento della generazione — l'endpoint API a cui invia il consenso, il CSS che carica, i percorsi dei logo. Cambiare APP_URL non riscrive gli script già esistenti. Finché non li rigeneri, i banner sui siti dei tuoi clienti continuano a chiamare il vecchio host: il consenso viene registrato contro l'origine sbagliata, o fallisce del tutto una volta che il vecchio indirizzo smette di rispondere.

docker compose exec app php bin/oci scripts:regenerate

6. Aggiorna lo snippet di incorporamento sui tuoi siti web

Lo snippet mostrato nella dashboard ora punta al nuovo dominio:

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

Se stai spostando un'installazione in produzione, tieni il vecchio nome host attivo e in proxy verso il nuovo finché non hai sostituito tutti gli incorporamenti. Il loader è il punto di ingresso per l'intero banner — un src non funzionante significa nessun banner di consenso.

7. Verifica end to end

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

Poi carica una pagina che incorpora il banner, accetta il consenso e verifica che la voce appaia sotto Consent Logs. Quel singolo ciclo completo verifica DNS, TLS, il loader, lo script generato e il percorso API insieme.

Risoluzione dei problemi

Il riferimento completo si trova con il codice: docs/custom-domain.md su GitHub.