Architettura

La divisione moderna app/public, l'albero completo del progetto e come una richiesta fluisce dal browser al database e ritorno.

In questa pagina

Architettura

CBGenesis segue il layout moderno di ColdBox: il codice dell'applicazione รจ completamente separato dalla webroot pubblica, quindi nulla sotto app/ รจ mai direttamente accessibile dal web.

Panoramica a livelli

flowchart TD
    A["Browser Request"] --> B

    subgraph B["public/ โ€” Webroot"]
        B1["Application.bx โ€” entry point, bootstraps ColdBox + ORM"]
        B2["index.bxm โ€” front controller"]
        B3["includes/ โ€” Vite compiled assets"]
    end

    B --> C

    subgraph C["app/ โ€” Application code (not web-accessible)"]
        C1["config/ โ€” ColdBox, Router, CacheBox, WireBox, Scheduler"]
        C2["handlers/ โ€” Controllers, auth, admin, audit log"]
        C3["models/ โ€” Entities, Services"]
        C4["views/ + layouts/ โ€” BXM templates"]
        C5["email_templates/ โ€” Token-based email bodies"]
        C6["interceptors/ โ€” Audit logging hook"]
    end

    C --> D

    subgraph D["resources/ โ€” Source assets"]
        D1["assets/js/ โ€” Alpine components + stores"]
        D2["assets/scss/ โ€” Bootstrap + custom SCSS"]
        D3["database/ โ€” Migrations + seeders"]
    end

    D --> E

    subgraph E["lib/ โ€” Dependencies (not source-controlled)"]
        E1["coldbox/, testbox/, modules/ โ€” qb, cbsecurity, cborm, ..."]
    end
Perchรฉ questa separazione?

Tutto ciรฒ a cui un aggressore potrebbe altrimenti navigare direttamente - codice sorgente degli handler, configurazione, template delle viste - semplicemente non vive sotto la webroot. app/Application.bx รจ una guardia di una riga con abort;, mantenuta solo affinchรฉ la convenzione del framework regga anche se un server web venisse mai configurato erroneamente per servire app/ direttamente.

Ciclo di vita della richiesta

Ogni richiesta entra attraverso public/Application.bx, che fa il bootstrap di ColdBox prima di passare il controllo al router e, infine, al tuo handler:

sequenceDiagram
    Browser->>+public/Application.bx: HTTP Request
    public/Application.bx->>+ColdBox Bootstrap: loadColdbox()
    ColdBox Bootstrap->>+Main Handler: onRequestStart
    Main Handler->>+Router: Match route
    Router->>+Target Handler: Dispatch event
    Target Handler->>+Service Layer: Business logic
    Service Layer->>+ORM / qb: Data access
    Target Handler->>+View / Layout: Render response
    View / Layout-->>-Browser: HTML + Vite assets

Main.bx (app/handlers/Main.bx) รจ l'handler a evento implicito collegato in app/config/Coldbox.bx:

  • onAppInit - esegue settingService.preFlightCheck(), seminando nel database ogni impostazione dell'app mancante
  • onRequestStart - carica prc.settings e prc.authUser per ogni richiesta
  • onException - il gestore delle eccezioni a livello di app

Interceptor

app/config/Coldbox.bx registra tre interceptor applicativi, in quest'ordine:

app/interceptors/AuditLogger.bx scrive nel registro di audit su quattro punti di intercettazione:

PuntoRegistrato
postAuthenticationUn accesso riuscito
preLogoutUna disconnessione
cbSecurity_onInvalidAuthenticationUna richiesta che richiedeva una sessione e non ne aveva nessuna
cbSecurity_onInvalidAuthorizationUn utente autenticato privo del permesso richiesto

app/interceptors/RateLimiter.bx si attiva su preProcess - prima del routing, prima di qualsiasi handler - e limita cinque azioni Auth non autenticate (login, registrazione, dimentica/reimposta password, attivazione invito) per IP client. Vedi Rate limiting per le impostazioni e il funzionamento.

app/interceptors/SSOAuthorization.bx gestisce il punto di intercettazione CBSSOAuthorization di cbSSO. Collega un'identitร  provider verificata al modello utente locale, applica la policy login-versus-linking, approvvigiona gli utenti quando consentito e crea la sessione cbauth. Vedi Single sign-on per il flusso di callback e il motivo per cui cbGenesis usa un handler personalizzato invece dell'integrazione generica cbAuth di cbSSO.

Aggiungi i tuoi all'array variables.interceptors in Coldbox.bx; si attivano nell'ordine di dichiarazione.

Task pianificati

app/config/Scheduler.bx registra tre task in background giornalieri, ciascuno con onOneServer() e withNoOverlaps() in modo che un deployment multi-istanza esegua ciascuno esattamente una volta:

TaskEsegue alleEliminaGovernato da
Purga i token API scaduti03:00Righe di user_api_tokens oltre la loro expirationDurata del token impostata al momento dell'emissione da cbApiTokenMaxValidityMonths (default 12 mesi) - vedi Impostazioni dell'app
Purga i remember token scaduti03:15Righe di user_remember_tokens oltre la loro expirationScadenza fissa impostata quando il token viene emesso (SecurityService/RememberTokenService)
Purga i vecchi registri di audit03:30Righe di audit_logs piรน vecchie della finestra di conservazionecbAuditLogRetentionDays (default 90; 0 disabilita la purga) - vedi Impostazioni dell'app

Tutti e tre chiamano un metodo purgeExpiredTokens()/purgeOlderThan() sul servizio proprietario invece di interrogare direttamente la tabella, cosรฌ la stessa logica di purga รจ raggiungibile (e testabile) al di fuori dello scheduler. Aggiungi un nuovo task nello stesso modo - vedi Estendere l'app.

Albero completo del progetto

cbgenesis/
โ”œโ”€โ”€ app/                      Application code
โ”‚   โ”œโ”€โ”€ Application.bx        Abort-only gate (prevents direct /app access)
โ”‚   โ”œโ”€โ”€ config/
โ”‚   โ”‚   โ”œโ”€โ”€ Coldbox.bx        Framework settings, environments, logging
โ”‚   โ”‚   โ”œโ”€โ”€ Router.bx         All application routes
โ”‚   โ”‚   โ”œโ”€โ”€ CacheBox.bx       Cache regions (default, template, sessions, rateLimit)
โ”‚   โ”‚   โ”œโ”€โ”€ WireBox.bx        DI container configuration
โ”‚   โ”‚   โ”œโ”€โ”€ Scheduler.bx      Scheduled tasks
โ”‚   โ”‚   โ””โ”€โ”€ modules/          Per-module settings (cbsecurity, cbauth, cborm, ...)
โ”‚   โ”œโ”€โ”€ handlers/              Controllers (Auth, Dashboard, Users, Roles, ...)
โ”‚   โ”œโ”€โ”€ layouts/                Admin, AuthCenter, AuthSplit, Main
โ”‚   โ”œโ”€โ”€ models/
โ”‚   โ”‚   โ”œโ”€โ”€ BaseEntity.bx      ORM base: timestamps, soft delete, memento
โ”‚   โ”‚   โ”œโ”€โ”€ BaseService.bx     Service base: cborm + qb + cache + validation
โ”‚   โ”‚   โ”œโ”€โ”€ security/            Role, Permission, APIToken, RememberToken,
โ”‚   โ”‚   โ”‚                        Passkey, UserActionToken, SecurityService, ...
โ”‚   โ”‚   โ””โ”€โ”€ system/              User, Setting, AuditLog + their services
โ”‚   โ”œโ”€โ”€ views/                  BXM templates, one folder per handler
โ”‚   โ”‚   โ””โ”€โ”€ _components/        Reusable UI partials (app, auth, ui)
โ”‚   โ”œโ”€โ”€ email_templates/       Token-based email body templates
โ”‚   โ”œโ”€โ”€ helpers/               ApplicationHelper.bxm โ€” global view helpers
โ”‚   โ””โ”€โ”€ interceptors/           AuditLogger, RateLimiter, SSOAuthorization
โ”œโ”€โ”€ public/
โ”‚   โ”œโ”€โ”€ Application.bx         Entry point โ€” ColdBox + ORM bootstrap
โ”‚   โ”œโ”€โ”€ index.bxm               Front controller placeholder
โ”‚   โ””โ”€โ”€ includes/               Vite production build output
โ”œโ”€โ”€ resources/
โ”‚   โ”œโ”€โ”€ assets/js/              Alpine entry, stores, components
โ”‚   โ”œโ”€โ”€ assets/scss/            Bootstrap + custom SCSS
โ”‚   โ””โ”€โ”€ database/
โ”‚       โ”œโ”€โ”€ migrations/         Schema migrations (cfmigrations)
โ”‚       โ””โ”€โ”€ seeds/              AdminData seeder
โ”œโ”€โ”€ tests/
โ”‚   โ”œโ”€โ”€ specs/integration/      Full HTTP-level specs
โ”‚   โ””โ”€โ”€ specs/unit/             Entity + service specs
โ”œโ”€โ”€ lib/                        Dependencies (gitignored, installed by `box install`)
โ”œโ”€โ”€ runtime/                    BoxLang engine config (boxlang.json)
โ”œโ”€โ”€ server.json                 CommandBox server config (engine, webroot, aliases)
โ”œโ”€โ”€ box.json                    Package manifest โ€” deps, scripts
โ”œโ”€โ”€ package.json                 NPM โ€” Alpine, Bootstrap, Vite, ESLint
โ”œโ”€โ”€ vite.config.mjs              Vite + coldbox-vite-plugin
โ””โ”€โ”€ .env.example                  Environment template

Lo stack

LivelloTecnologia
RuntimeBoxLang 1.0+ (JVM)
FrameworkColdBox HMVC (bleeding edge)
CLI / ServerCommandBox + BoxLang MiniServer
Dependency InjectionWireBox
Sicurezzacbsecurity + cbauth (basata su sessione + JWT)
DatabaseMySQL, MariaDB, PostgreSQL e MSSQL tramite Hibernate ORM (cborm); tutti e quattro i target di database sono supportati e coperti dal workflow di test del database del progetto
Query Builderqb (SQL fluente)
Migrazionicfmigrations
Validazionecbvalidation
Emailcbmailservices
Serializzazionemementifier
FrontendBootstrap 5.3 ยท Alpine.js 3.x ยท Vite 6
IconePhosphor Duotone
TooltipTippy.js
Modifica questa pagina Scarica Markdown Ultimo aggiornamento Oct 1, 2026, 2:02:30 PM