Home / Indice sezione
 www.icosaedro.it 

 Organizzare siti WEB per funzioni in PHP - Soluzione generale

Ultimo aggiornamento: 2008-01-21

Nell'articolo precedente abbiamo proposto un modello di programmazione WEB per funzioni usando solo le ancore HTML. Qui esaminiamo il problema della gestione dei FORM e dei bottoni. Inoltre perfezioneremo ulteriormente il nostro codice in modo che non sia più necessario eseguire la validazione dei parametri delle funzioni.

Indice

Implementare i FORM e i bottoni
I parametri dell'URL non sono affidabili
Proteggere l'integrità dei parametri dell'URL
Meccanismo di chiamata delle funzioni rivisto
Application Programming Interface (API)
Implementazione
Conclusioni
Limitazioni per Apache WEB server
Riferimenti

Implementare i FORM e i bottoni

Vogliamo poter assegnare una funzione target per ogni bottone. Questo è coerente con l'impostazione generale secondo la quale ogni volta che l'utente fa un click su di un'ancora o su di un bottone viene chiamata una funzione specifica del nostro programma, eventualmente con dei parametri appositamente predisposti.

Per fissare le idee, consideriamo ad esempio la classica rubrica telefonica, dove il record pk=1234 corrisponde al signor "Mario Rossi". La maschera qui sotto mostra i dati del record e permette di salvare le modifiche (bottone Salva) oppure cancellare il record (bottone Rimuovi):


Nome:
Cognome:
Telefono:
  


Il bottone Salva sarà associato alla funzione SalvaRecord(1234), che acquisisce il POST e salva i dati aggiornati nel record pk=1234. Invece il bottone Rimuovi sarà associato alla funzione RimuoviRecord(1234), che rimuove il record.

I parametri dell'URL non sono affidabili

Abbiamo visto nel precedente articolo che la funzione Anchor() permette di definire un'ancora, impostare la funzione associata, e definire anche dei parametri. Ad esempio:

Anchor("Rimuovi", "RimuoviRecord", "pk", "1234");

produce un'ancora che, se cliccata, causa la chiamata della funzione RimuoviRecord() con parametro di query HTML pk=1234. L'intenzione è che il parametro pk sia la chiave primaria del record da cancellare dal DB. Tuttavia non possiamo essere certi che l'utente ritorni un parametro corretto. Infatti l'utente potrebbe alterare deliberatamente o accidentamente l'URL, causando effetti imprevisti. Basterebbe immettere nella barra degli indirizzi del browser un URL confezionato così:

http://www.nostrosito.it/programma.php?fun=RimuoviRecord&pk=567

per causare la cancellazione del record di chiave primaria 567. Probabilmente questo fatto non sarebbe molto rilevante nella nostra banale applicazione dell'agenda telefonica personale, ma sarebbe potenzialmente disastroso in applicazioni più articolate esposte al pubblico o a personale non fidato.

Ma non solo i parametri possono essere artefatti, possono anche mancare del tutto! Cosa succederebbe se la funzione RimuoviRecord() procedesse ciecamente ad eseguire la cancellazione di un record di chiave primaria vuota? Probabilmente avremmo l'emissione di un errore per istruzione SQL non ben formata.

Ancora più grave sarebbe il caso in cui un utente malizioso, scoperta la breccia nella sicurezza del nostro programma, cominciasse a sperimentare l'inclusione di stringhe opportunamente confezionate per il parametro pk in modo da indurre il DB ad eseguire istruzioni arbitrarie.

Nella precedente implementazione dell'esempio 1 l'istruzione switch assicurava che almeno il nome della funzione da chiamare risultasse tra quelli previsti, perché diversamente veniva chiamata d'uffico la Home() che presentava la home page. Nessun controllo però avveniva sugli altri eventuali parametri, e pertanto la funzione doveva eseguire il necessario controllo sanitario. Questa strategia è tediosa, inefficiente, e prona agli errori. Vediamo ora come risolvere la questione in modo più elegante.

Proteggere l'integrità dei parametri dell'URL

Per assicurare che i parametri degli URL che ritornano dal client non siano stati alterati, possiamo ricorrere a un Hashed Message Authentication Code (HMAC). Si tratta di un codice calcolato sulla base del messaggio da controllare e di una chiave segreta nota solo al server. L'URL che invieremo al client sarà quindi composto dai parametri veri e propri e dall'HMAC. Quando il client ci rispedirà l'URL, il server dovrà estrarre i parametri e l'HMAC, e quindi dovrà verificare che l'HMAC ritornato sia valido. In definitiva, l'HMAC è una sorta di sigillo di autenticità che viene applicato dal server e che può essere verificato solo dal server.

Tra i vari algoritmi che si possono utilizzare, ne scegliamo uno basato sulla funzione digest MD5 applicata in questo modo (vedi ad esempio [Schneier] par. 18.14):

HMAC = MD5( CHIAVE . MD5( CHIAVE . PARAMETRI ) )

ovvero: la chiave segreta viene concatenata ai parametri e ne viene calcolato il digest MD5; il risultato viene concatenato di nuovo con la chiave e ne viene calcolato il digest; il digest risultante è l'HMAC che useremo.

Ottenuto l'HMAC, inseriamo nell'URL i parametri voluti e l'HMAC calcolato. Se il client ci ritornerà questo URL, dovremo estrarre i parametri, ricalcolarne l'HMAC e confrontarlo con l'HMAC ritornato. Se i due HMAC, cioè quello ritornato del client e quello calcolato di nuovo, coincidono, allora avremo la certezza quasi assoluta che i parametri ritornati dal client sono proprio quelli generati dal nostro programma nel momento in cui la pagina WEB era stata prodotta. Se invece i due HMAC non corrispondono, allora i parametri non sono validi e avremo rilevato una condizione anomala.

Meccanismo di chiamata delle funzioni rivisto

Soluzione per le ancore. I nostri URL conterranno 3 parametri: il primo, di nome fun contiene il nome della funzione; il secondo, di nome args contiene l'array degli argomenti della funzione; il terzo, di nome mac, contiene l'HMAC calcolato sulla base dei primi due e della chiave segreta.

Siccome gli argomenti di una funzione possono essere oggetti di tipo arbitrario, useremo la funzione serialize() per convertirli in una stringa di byte, e la funzione urlencode() per inserire il tutto nell'URL. Siccome i dati serializzati sono di tipo binario, eseguo anche una codifica base64_encode() prima di eseguire l'urlencode in modo da ridurre un po' la lunghezza degli URL prodotti. Ad esempio, la chiamata alla funzione

Anchor("Rimuovi", "RimuoviRecord", 1234);

produce questo codice HTML (scomposto in due righe per esigenze di formattazione):

<a href="/php/esempio2.cgi?fun=RimuoviRecord&args=YToxOntpOjA7aToxMjM0O30%3D
&mac=67ff4ea38308dc09dfae80c19f23e1f3">Rimuovi</a>

Possiamo togliere lo switch sui nomi delle funzioni, che ci costringeva a elencarle tutte. Ci possiamo risparmiare questa seccatura usando la funzione call_func_array() del PHP. Questa funzione richiede due argomenti: il nome della funzione da chiamare e un array degli argomenti.

In definitiva, se l'utente cliccherà su questa ancora, verrà chiamata automaticamente la funzione RimuoviRecord(1234).

Soluzione per i FORM. Per i FORM la cosa si complica un pochino, ma non più di tanto. Per prima cosa osserviamo che ad un bottone si possono assegnare due proprietà: il nome con l'attributo name, e il valore con l'attributo value. Ad esempio il codice HTML seguente

<INPUT type=submit name=bottoneOk value="OK">

produce un bottone "OK". Se si preme questo bottone, il client ritorna al server il parametro bottoneOk=OK, cioè ritorna il nome del bottone e il suo valore. Oltre al bottone premuto, il client ritorna al server anche tutti i campi visibili e quelli nascosti.

Se vogliamo differenziare il comportamento del programma a seconda del bottone premuto, dobbiamo basarci o sul nome del bottone o sul suo valore. Il valore del bottone non è adatto, sia perché il programma potrebbe subire la localizzazione in diverse lingue, sia perchè in una pagina ci potrebbero essere diversi bottoni con la stessa dicitura riportata su di essi. Dobbiamo quindi basarci sul nome. Decidiamo allora di numerare i bottoni progressivamente, e di chiamarli button1, button2, button3, e così via. Per ogni bottone aggiungiamo anche dei campi nascosti (hidden) che conservano i valori del nome della funzione, degli argomenti e dell'HMAC di controllo. Ad esempio, la chiamata alla funzione Button() come questa

Button("Rimuovi", "RimuoviRecord", 1234);

produrrà nella pagina HTML un codice simile a questo (anche qui scomposto in più righe per maggiore chiarezza):

<INPUT type=hidden name=fun1 value=RimuoviRecord>
<INPUT type=hidden name=args1 value="YToxOntpOjA7aToxMjM0O30=">
<INPUT type=hidden name=mac1 value=a2534ea1548ed3624644accea00c256c>
<INPUT type=submit name=button1 value="Rimuovi">

Il parametro hidden fun1 contiene il nome della funzione da chiamare se il bottone viene premuto; args1 è l'array (serializzato ed opportunamente codificato con base64_encode()) degli argomenti della funzione; mac1 è l'HMAC dei due campi precedenti. In definitiva, se l'utente cliccherà su questo bottone, verrà richiamata la funzione RimuoviRecord(1234).

Similmente per il secondo bottone avremo dei campi hidden di nome fun2, args2, mac2, oltre al bottone vero e proprio button2. In questo modo abbiamo risolto anche il problema di associare una funzione specifica ad ogni bottone.

In definitiva, per creare un FORM con due bottoni A e B che chiamano le funzioni a() e b("Mario Rossi", 456) basterà scrivere un codice simile a questo:

Form();
Button("A", "a");
Button("B", "b", "Mario Rossi", 456);
Form_();

Eventuali campi di input si possono inserire all'interno del FORM nel modo tradizionale.

Application Programming Interface (API)

Siamo quasi giunti alla fine del viaggio. Prima di vedere l'esempio completo, riassumiamo le funzioni che potremo usare per implementare le nostre pagine WEB dinamiche:

Anchor(string $testo, string $fun, ...)
Emette un'ancora che, qualora cliccata, causa la chiamata della funzione $fun con gli eventuali argomenti indicati.

Form()
Form_()

Rispettivamente, aprono e chiudono un form. Ad ogni chiamata alla prima funzione deve corrispondere una chiamata alla seconda. Le due chiamate non si possono incrociare. Quando si preme un bottone, il client invia al server solo i campi contenuti nel form cui appartiene il bottone.

Button(string $testo, string $fun, ...)
Emette un bottone che, qualora cliccato, causa la chiamata della funzione $fun con gli argomenti indicati. La funzione potrà acquisire i valori dei campi del form come di consueto attraverso l'array $_POST[]. Su questi ultimi si dovrà procedere alla validazione secondo quanto richiesto dall'applicazione specifica.

Osserviamo che si possono inserire ancore all'interno dei form, e che si possono inserire più form in una stessa pagina; i bottoni devono stare all'interno di un form.

Il codice dell'esempio riporta anche altre funzioni di utilità per la costruzione delle pagine WEB, come Testa($titolo) e Piede() che aprono e chiudono una pagina. Agendo su queste funzioni è possibile cambiare rapidamente l'aspetto del nostro sito.

Implementazione

Finalmente vediamo l'implementazione del tutto. Il codice questa volta è un pò lungo e non lo riporto in questa pagina. Lo puoi vedere cliccando qui sotto:

La logica di funzionamento è piuttosto semplice:

Conclusioni

Lo strumento che stiamo sviluppando comincia a prendere forma e potrebbe già risultare utile in alcune applicazioni pratiche. Lo sviluppo di applicazioni articolate si semplifica e il risultato è un codice pulito e facilmente manutenibile.

Rimangono aperti ancora alcuni problemi che esamineremo negli articoli seguenti.

Limitazioni per Apache WEB server

Esistono delle limitazioni alla lunghezze delle richieste GET: il server Apache dispone della direttiva LimitRequestLine il cui valore default è di 8190 bytes. Questo pone un limite al numero e alla lunghezza degli argomenti delle funzioni.

Riferimenti

[Schneier] B. Schneier, "Applied Criptography", Wiley, 1996.


Umberto Salsi
Commenti
Contatto
Mappa
Home / Indice sezione
An abstract of the lastest comments from the visitors of this page follows. Please, use the Comments link above to read all the messages or to add your contribute.

2018-05-10 by Umberto Salsi <salsi@icosaedro.it>
Re: web-per-funzioni a quando gli articoli previsti?
Guest wrote: [...] Avevo del codice da parte, ma non mi decidevo a dagli una sistemata in modo da renderlo adatto alla pubblicazione. Adesso è disponibile tutto insieme alla libraria standard di PHPLint; il seguente tutorial http://www.icosaedro.it/phplint/web spiega tutte le funzionalità supportate, e cioè: - Gli sticky form che, con i relativi controlli, permettono di creare semplici form entro-contenuti, con eventi associabili a metodi. - Il "web per funzioni" o "bt_", che permette di collegare fra loro eventi delle pagine associandoli a funzioni del programma (normalmente metodi statici di classe). - I "bt form", che sono la logica integrazione tra i form e bt_ e permettono di realizzare applicazioni articolate. - Esempio di sito web realizzato con bt form, a cui bisogna aggiungere il "web commenting system" con il quale sto scrivendo questo stesso commento. Quindi abbiamo tutto: tutorial, codice open source ed esempi. Ciao, - Umberto Salsi[more...]

2010-08-12 by Guest
web-per-funzioni a quando gli articoli previsti?
Ho scoperto recentemente il tuo sito è meravigliosamente interessante. Vedendo la data degli articoli "web per funzioni" credo che tu non abbia più intenzione di proseguire sull'argomento. Sarebbe un peccato! Credo che molti utenti del tuo sito ti sarebbero grati se invece continuassi a condividere le tue ottime conoscenze. Qualunque cosa tu decida ...grazie per gli articoli presenti. Buon lavoro.[more...]

2008-09-16 by Umberto Salsi
Re: ottimo lavoro ma....
Anonymous wrote: [...] Il file della chiave per il calcolo dell'HMAC è un qualsiasi file non leggibile dai visitatori del sito che si può collocare fuori dalla DOCUMENTROOT del sito: define('MAC_KEY_FILE', '../../MAC_KEY'); In alternativa se non è disponibile una directory fuori dal DOCUMENTROOT (molti hosting economici ricadono in questo caso) si può sempre usare il solito trucco di definire un file PHP di nome "key.php" che contiene qualcosa come <?php # abcdefghij ?> dove il commento abcdefghij è una stringa arbitraria di caratteri casuali. La costante MAC_KEY_FILE diventa allora: define('MAC_KEY_FILE', 'key.php'); In questo modo i visitatori del sito, anche se tentano di visualizzare il contenuto del file key.php, otterranno una pagina bianca. [more...]

2008-09-15 by Guest
ottimo lavoro ma....
chi esmina il codice trovera una define di mac file che per chiarezza potrebbe essere aggiunto al codice per avere un esempio completo.[more...]

2008-08-26 by Guest
the next one?
dovrò aspettare molto per i prossimi articoli? :) davvero un ottimo lavoro [more...]