A partire da 4D 21, gli sviluppatori di 4D possono ora avere il pieno controllo sulle risposte HTTP utilizzando un semplice file di configurazione: HTTPRules.json. Se state cercando di migliorare la sicurezza, ottimizzare le prestazioni o gestire l’accesso a risorse statiche, questa funzione vi offre la flessibilità necessaria, senza scrivere una sola riga di codice.
Scopriamo le funzionalità e come utilizzarle.

Come si applicano le regole

Per attivare la funzione, occorre inserire un file HTTPRules.json nella cartella Sources del progetto.
In alternativa, è possibile definire le regole in modo programmatico, definendo le regole nell’attributo settings. rules e passando l’oggetto settings alla funzione Web server. start( ). Questo sostituisce le regole definite in qualsiasi file esistente.

Il contenuto del file o dell’attributo settings. rules è un insieme di regole.
Ogni regola è un oggetto ed è definita da un modello di espressione regolare (regexPattern) che corrisponde all’URI della richiesta.

Le azioni di una regola sono definite dal loro attributo:

• setHeaders: modificare le intestazioni della risposta HTTP.
• addHeaders: aggiungere intestazioni alla risposta HTTP.
• removeHeaders: rimuovere intestazioni dalla risposta HTTP.
• denyAccess: negare o consentire l’accesso a una risorsa.
• redirect: per reindirizzare la richiesta HTTP.
• status: definire uno stato di risposta HTTP personalizzato.

Quando il server HTTP viene avviato con delle regole, le regole prese in considerazione sono ottenibili all’interno dell’attributo Web server.rules.
Si noti che le regole vengono valutate in modo sequenziale e che più regole possono essere applicate a una singola richiesta.

AZIONI DESCRIZIONE

Impostare intestazioni personalizzate

È possibile aggiornare le intestazioni esistenti della risposta HTTP e crearle se non esistono.
Questa azione è definita dall’attributo setHeaders. Si tratta di un oggetto contenente le coppie chiave-valore delle intestazioni da impostare nella risposta HTTP.

Esempio:

{
"regexPattern": "/(.*)",
"setHeaders": {
"X-Frame-Options": "SAMEORIGIN",
"Content-Security-Policy": "default-src 'self'"
}
}

Con questa regola, tutte le risposte HTTP conterranno le intestazioni X-Frame-Options e Content-Security-Policycon i valori definiti, oltre a quelli definiti dal server HTTP 4D.

Aggiungere intestazioni personalizzate

È possibile aggiungere intestazioni personalizzate nella risposta HTTP. È particolarmente utile per le intestazioni che possono avere diverse istanze, come i cookie.
Questa azione è definita dall’attributo addHeaders. Si tratta di un oggetto contenente le coppie chiave-valore delle intestazioni da aggiungere alla risposta HTTP.

Esempio:

{
"regexPattern": "/(.*)",
"addHeaders": {
"Set-Cookie": "myCookie=123456; Max-Age=14400"
}
}

Con questa regola, tutte le risposte HTTP conterranno un’altra intestazione Set-Cookie con il suo valore definito, oltre a quelle definite dal server HTTP 4D o dalle proprie.

Rimuovere le intestazioni

È possibile rimuovere le intestazioni indesiderate dalla risposta, come Server, che espone la versione di 4D.
Questa azione è definita dall’attributo removeHeaders. Si tratta di un insieme di chiavi di intestazione da rimuovere dalla risposta HTTP.

Esempio:

{
"regexPattern": "/(.*)",
"removeHeaders": ["Server", "X-Frame-Options"]
}

Con questa regola, le intestazioni Server e X-Frame-Options saranno rimosse da tutte le intestazioni di risposta HTTP.

⚠️ Alcune intestazioni non possono essere aggiornate, aggiunte o rimosse, ad esempio Date e Content-Length.

Negare/consentire l’accesso alle risorse

È possibile bloccare l’accesso a URI specifici restituendo uno stato 403 Forbidden per impostazione predefinita.
Questa azione è definita dall’attributo denyAccess. È un booleano: vero per negare l’accesso e falso per consentirlo.

Esempio:

{
"regexPattern": "/private/(.*)",
"denyAccess": true,
}

Con questa regola, tutte le risorse della cartella /private/ e delle sottocartelle non saranno consegnate.

È anche possibile consentire esplicitamente l’accesso alle sottocartelle:

Esempio:

{
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}

Con questa regola, tutte le risorse della cartella /private/allowed/ e delle sottocartelle sono accessibili, anche se la regola precedente che nega l’accesso alla cartella madre /private/ è definita.

Reindirizzare le richieste

È possibile reindirizzare le richieste a un altro URL. È possibile specificare il codice di stato (301 per permanente, 302 per temporaneo per impostazione predefinita).
Questa azione è definita dall’attributo redirect. Si tratta di un testo contenente l’URL di reindirizzamento di base.

Esempio:

{
"regexPattern": "^/images/(.*)",
"redirect": "https://cdn.example.com/images/",
"status": 301
}

Con questa regola, tutte le risorse della sottocartella images saranno reindirizzate al CDN definito.
Si noti che il “^” che inizia lo schema regex è importante nel caso del reindirizzamento, per evitare che vengano restituiti URI errati.

Impostare codici di stato personalizzati

È possibile sovrascrivere il codice di stato predefinito per una risposta HTTP.
Questa azione è definita dall’attributo status. È un numero restituito come codice di stato dalla risposta HTTP.

Esempio:

{
"regexPattern": "^/manutenzione.html",
"status": 503
}

Con questa regola, quando viene richiesta la pagina maintenance.html, il codice di stato restituito sarà 503.

⚠️ Assicurarsi che lo stato definito sia coerente con la risposta inviata dal server HTTP!

Combinare azioni e regole

Diverse azioni possono essere combinate in una regola se condividono lo stesso modello regexP.

Esempio:

{
"regexPattern": "/docs/(.*).html",
"addedHeaders": {
"Cache-Control": "max-age=3600"
},
"removedHeaders": ["X-Powered-By"]
}

Questa regola si applica a tutti i file HTML inseriti nella sottocartella docs.

Le regole possono anche essere combinate in un ordine logico per configurare completamente le risposte del server HTTP.

Esempio di raccolta completa di regole:

[
{
"commento": "Tutte le richieste: consentire il metodo GET, rimuovere l'intestazione 'Server' e impostare le intestazioni di sicurezza",
"regexPattern": "/(.*)",
"setHeaders": {
"Allow": "GET",
"X-Frame-Options": "SAMEORIGIN",
"Content-Security-Policy": "default-src 'self'"
},
"removeHeaders": [
"Server"
]
},
{
"comment": "Richieste REST: consentire il metodo POST",
"regexPattern": "/rest/(.*)",
"addHeaders": {
"Allow": "POST"
}
},
{
"comment": "File HTML nella cartella 'doc': impostare il controllo della cache",
"regexPattern": "/docs/(.*).html",
"setHeaders": {
"Cache-Control": "Max-Age=3600"
},
"removeHeaders": [
"X-Powered-By"
]
},
{
comment": "Stato 503 sulla pagina 'manutenzione'",
"regexPattern": "^/manutenzione.html",
"status": 503
},
{
"comment": "Reindirizza i file CSS e JS",
"regexPattern": "^(.*\\\\.(css|js))",
"redirect": "https://cdn.example.com/"
},
{
"comment": "Reindirizza le immagini con codice di stato permanente",
"regexPattern": "^(.*\\\\.(jpg|jpeg|png|gif))",
"redirect": "https://cdn.example.com/images/",
"status": 301
},
{
"comment": "Negare l'accesso a tutte le risorse inserite nella cartella 'private'",
"regexPattern": "/private/(.*)",
"denyAccess": true
},
{
"comment": "Consenti l'accesso a tutte le risorse collocate nella cartella 'private/allowed'",
"regexPattern": "/private/allowed/(.*)",
"denyAccess": false
}
]

Riepilogo

Con HTTPRules.json, 4D diventa un server HTTP più potente e flessibile. È ora possibile:

• Aggiungere, modificare o rimuovere intestazioni
• Bloccare o consentire gli accessi
• Reindirizzare le richieste
• Impostare codici di stato personalizzati

Non c’è bisogno di una complessa logica di filtraggio tramite codice, basta configurare il file HTTPRules.json e via!
E se le vostre applicazioni hanno bisogno di regole personalizzate (ad esempio, regole di sicurezza) a seconda degli ambienti o dei clienti, è molto facile farlo con il comando Web server !
Siete pronti a semplificare la vostra distribuzione web? Iniziate a usare le regole oggi stesso.