- Dockerfile: ARG PHP_VERSION=8.3.36 e FROM php:${PHP_VERSION}-fpm al posto
del tag mobile php:8.3-fpm, che la cache di Docker poteva risolvere sulla
8.3.35 vulnerabile. Una build ora prende la versione corretta o fallisce.
- phpredis da GitHub (versione fissata) invece di pecl.php.net, che il
giorno della patch rispondeva 504 e bloccava la build.
- Test contro il ritorno a un tag mobile o a una versione vulnerabile.
- PHP_VERSION passabile dal compose solo per prove locali.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modulo S-13
- Il PDF scrive sopra il modulo ufficiale (FPDI, matrice convertita in PDF 1.4)
invece di ricostruirlo in HTML: 20 righe per foglio come l'originale.
- Una riga per ogni territorio attivo; riporto dell'ultimo rientro prima
dell'anno; assegnazioni a cavallo d'anno su entrambi i fogli; scelta per
data e non per anno registrato; nomi come "Cognome I.".
- Logica spostata in App\Services\Registro\ModuloS13.
Integrità dei dati
- Export/import XML (e quindi backup/ripristino): le date non slittano più di
un giorno; i file vecchi in UTC tornano al giorno giusto.
- Import XML: rifiuta file estranei o incompleti senza toccare i dati, errore
con riga e motivo, territori senza zona importati con il loro storico,
caratteri di controllo rimossi in export, chi importa conserva password e
ruolo di amministratore.
- Assegnazioni: assegnazioneCorrente corretta (filtro dentro ofMany), periodi
sovrapposti rifiutati in Assegna e Registro sotto lock, anno di servizio
ricavato dalla data, niente date future nel Registro.
- Utenti: non si declassa sé stessi né l'ultimo amministratore.
- Entrypoint: non sovrascrive più la copia persistente di APP_KEY con un
valore diverso; serve APP_KEY_ROTATE=1 per un cambio voluto.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Il Dockerfile compilava l'applicazione in /app-src mentre il runtime girava
da /var/www/html, popolato solo dal bind mount del sorgente: l'immagine
costruita non veniva mai usata. L'entrypoint rieseguiva composer install e
npm run build a ogni avvio, dentro il container. Su Dokploy, senza sorgente
sull'host, questo significava build a runtime a ogni deploy.
Ora vendor/ e public/build sono compilati in stage separati e copiati
nell'immagine finale. I container di produzione non montano il sorgente e
non eseguono build all'avvio: un redeploy e' build, migrazioni, online.
- Dockerfile multi-stage (composer, node, runtime)
- nginx e php-fpm nello stesso container via supervisor: con container
separati nginx avrebbe bisogno di una copia di public/ e del volume
storage solo per servire file statici
- clear_env = no in www.conf, senza cui php-fpm nasconde a Laravel tutte
le variabili d'ambiente
- configurazione da ambiente di processo invece di .env riscritto con sed;
il compose fissa solo i valori dettati dalla topologia
- fail-fast su APP_URL, DB_PASSWORD, DB_ROOT_PASSWORD, REDIS_PASSWORD
- servizio scheduler dedicato: schedule:work non veniva mai eseguito,
quindi la pulizia dell'audit log non e' mai partita
- solo il container app esegue le migrazioni, per evitare che due
container in gara lascino uno schema applicato a meta'
- healthcheck separati per worker e scheduler, che non espongono HTTP
- docker-compose.dev.yml per lo sviluppo locale
- documentazione unificata in README.md e HANDOFF.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Key saved to storage/app/.app_key (persistent volume)
- On redeploy: restored automatically from volume
- On first deploy: generated and saved
- No manual Dokploy env var needed
- Copy app code into PHP image, sync to shared volume at startup
- Use named volume (app_code) shared between app and nginx
- Build nginx image with embedded config (no bind mounts)
- Add .dockerignore to optimize image build
- Build context moved to project root for both services
- Entrypoint now overrides .env with Docker environment variables
- Supports all key vars: APP_KEY, APP_URL, DB_*, REDIS_*
- Warns to save APP_KEY in Dokploy if auto-generated
- Fixes DecryptException on proclamatori encrypted fields
