Attenzione: Questo articolo è un’introduzione alle possibili soluzioni adottabili per offuscare il nostro codice, le varie soluzioni saranno approfondite in una serie di articoli successivi.

Penso che molti programmatori PHP sarebbero contenti di poter proteggere il loro codice da sguardi indiscreti o da utilizzi non autorizzati.
Si pensi per esempio a quando si realizza una bozza di un progetto, sareste contenti di sapere che il committente lo distribuisce a vostra insaputa? A me no di certo. Potremmo ospitare la bozza su un nostro server senza consegnare il codice, potremmo anche rimuovere il progetto dopo la sua analisi da parte del cliente, ma se ciò non fosse possibile per motivi di stile o per altri motivi dovremmo affidarci ad altre tecniche.

Esistono due principali metodi che ci permettono di proteggere il nostro codice, attenzione però: il livello di protezione non è mai totale (è cioè sempre possibile aggirare il metodo di protezione per ottenere il sorgente dello script) ma con un po’ di fortuna riusciremo ad allontanare il nostro codice da sguardi indiscreti, eccoli:

Il primo metodo è molto semplice: nominare le variabili in modo da renderle simili fra loro, rimuovere gli spazi e non andare a capo, come nell’esempio (non testato), che vi fa capire in linea di massima ciò che intendo:

[source:Php]
<?php
$mysql_address=”localhost”;
$mysql_username=”root”;
$mysql_password=”";
$mysql_database=”mio_database”;
$mysql_connessione=mysql_connect($mysql_address,$mysql_username,$mysql_password);
mysql_select_db($mysql_database,$mysql_connessione);
$query=”SELECT * FROM $mysql_database.visite WHERE data=’19910429′”;
$risultato=mysql_query($query, $mysql_connessione);
$quanti=mysql_num_rows($risultato);
echo “il 29 aprile 1991 sono venuti a trovarci $quanti visitatori!”;
mysql_close($mysql_connessione);
?>
[/source]
Questo diventerà
[source:Php]
<?php $mxazfhm=”localhost”;$mxgzfhm=”root”;$mxazfbm=”";$mxasfhm=”mio_database”;$mxazthm=mysql_connect($mxazfhm,$mxgzfhm,$mxazfbm);mysql_select_db($mxasfhm,$mxazthm);$mcazfhm=”SELECT * FROM $mxasfhm.visite WHERE data=’19910429′”;$mxzafhm=mysql_mcazfhm($mcazfhm, $mxazthm);$maczfhm=mysql_num_rows($mxzafhm);echo “il 29 aprile 1991 sono venuti a trovarci $maczfhm visitatori!”mysql_close($mxazthm);?>
[/source]

Esistono software come PHP Obfuscator (nell’immagine di questo articolo) che automatizzano il processo di sostituzione.

Un utente esperto sarà indubbiamente in grado di risalire al codice originale in poco tempo: il livello di protezione di questa soluzione è proporzionale alla sua facilità d’uso, cioè basilare. E’ però vero che potremo utilizzare lo script senza dover installare alcun software aggiuntivo, e questo è davvero un bel vantaggio.

Non vi preoccupate se l’efficacia del metodo precedentemente descritto non vi soddisfa: esiste un secondo metodo: utilizzare software progettati per gestire la protezione (quella seria) del nostro codice (come Zend Guard).
Come funzionano questi software? E’ bene aver presente la strada che percorre il nostro script prima di tornare nel browser: esso infatti, dopo essere stato riconosciuto in una pagina, viene interpretato e successivamente viene restituito l’output che verrà caricato all’interno della pagina. Il riconoscimento dei frammenti di codice avviene tramite la ricerca dei tags php (in genere <?php; ?>), dopo aver riconosciuto il codice esso viene trasformato in linguaggio macchina, ecco il problema: il codice PHP deve essere “puro”, ovvero non cifrato per essere comprensibile! I software che si occupano di cifrare e poi decifrare il codice (l’analisi ed il giudizio di questi saranno il tema di una serie di articoli che approfondiranno l’argomento) inseriscono un controllo del sorgente tra la fase di riconoscimento del codice e quella di trasformazione in linguaggio macchina, se il controllo troverà files cifrati li trasformerà nel linguaggio comprensibile dal compilatore, ovvero quello “puro”. Attenzione però: non tutti i servizi di hosting offrono la possibilità di utilizzare queste soluzioni.

Indice: Introduzione

Parlando di stili di programmazione sono molte le idee su come andrebbero scritte le singole linee di codice. La prima è sicuramente quella che riguarda la lunghezza delle varie linee, non c’è solo questo ma molto altro. Gli sviluppatori dovrebbero dare attenzione al volume delle righe (proprio il numero) e la densità delle stesse (numero di operazioni).

Lunghezza
Dal PEAR style guide apprendiamo che la lunghezza della singola linea di codice non deve eccedere i 75-85 caratteri. Questo limite non è dettato da problemi di wrapping errato o dimensioni dei monitor non sufficienti ad una giusta visualizzazione si tratta piuttosto di un limite cognitivo dell’individuo che si trova a leggere il codice.

Molto tempo fa alcuni studi sull’editoria sancirono che un lettore medio non potesse andare oltre alle 10-12 parole (5 caratteri) per riga senza avere problemi a comprendere il significato di ciò che ha letto nel contesto più ampio della totalità delle righe. Ora maggiorando questo limite di un 25-50% si arriva fino a 15 parole che a 5 caratteri l’una ci portano a 75 caratteri per riga.

Detto questo è chiaro che la lunghezza non è un parametro oggettivo, ogni programmatore ha i propri limiti quindi quello che io riesco a leggere e comprendere in una stringa di testo sarà sicuramente diverso dalla maggior parte degli altri programmatori.

Volume e densità
Alcuni programmatori credono che si dovrebbe scrivere quanto più possibile in ogni singola riga per ridurne il numero complessivo. Facendo questo però riducono il volume a discapito della densità (complessità) della singola riga di codice. Andando ad aumentare la densità di una riga si aumenta in modo inversamente proporzionale la sua leggibilità, il codice è composto da molte azioni non si tratta di prosa…inoltre scrivendo troppe istruzioni nella stessa linea si perde di vista il flusso logico di ciò che si sta realizzando.

E’ quindi preferibile privilegiare la leggibilità con un po’ di buon senso pensando al futuro e pensando a chi metterà mano al vostro codice. Infatti lavorando in questo modo tra un anno o più potrete lavorare sul vostro codice riuscendo a capire facilmente come funziona, lo stesso varrà per qualche altro programmatore.

Aumentare il volume delle righe e diminuirne la densità ha 3 benefici:

1. maggiore leggibilità del codice
2. la maggiore leggibilità rende più semplice la comprensione del codice e del suo flusso
3. in acuni casi (vi rimando all’esempio originale) il codice guadagna in velocità di esecuzione

Compromesso
E’ dunque lasciato al programmatore trovare il giusto compromesso tra volume e densità senza sbilanciarsi in situazioni estreme a favore di uno o dell’altro parametro. L’esperienza insegnerà sicuramente ad affinare la propria tecnica ed agire di conseguenza.

Personalmente ritengo molto importante lo stile di scrittura del codice includendo tra l’altro il corretto utilizzo dell’indentazione e l’inserimento dei commenti (sensati) per rendere il codice semplice da comprendere a distanza di tempo. Lavorare dopo alcuni giorni su del codice è un conto, farlo anche solo dopo alcuni mesi può diventare un’impresa ardua se il codice non è scritto in modo rispettoso si queste semplice regole.

E voi come agite, cosa ne pensate di queste regole che potremmo definire “best-practice”?