Latoserver.it/ PHP 4.2.0, una piccola svolta

Alcune novità introdotte nelle ultime release di PHP sono destinate a cambiare significativamente il modo di programmare con tale linguaggio e ad imporre un'accurata revisione del codice esistente. Vediamo di cosa si tratta

Latoserver.it/ PHP 4.2.0, una piccola svoltaRoma - Alcune novità introdotte nelle ultime release di PHP sono destinate a cambiare il modo di programmare in tale linguaggio, in particolare per quanto riguarda la gestione delle variabili comunemente definite "esterne". Le variabili esterne sono le variabili d'ambiente, le variabili relative al server web, le variabili registrate nelle sessioni, le variabili provenienti da richieste HTTP (GET o POST), i cookies.

Fino ad oggi l'accesso alle variabili esterne era sempre avvenuto in modo molto semplice: la configurazione predefinita dell'interprete PHP, infatti, prevedeva che esso le rendesse disponibili automaticamente sotto forma di variabili globali.

Questo comportamento, a partire dal recente rilascio della versione 4.2.0 del linguaggio, viene considerato deprecato ed è quindi destinato a diventare l'eccezione e non più la regola.
Da un punto di vista pratico questa piccola svolta consiste nel modificare da On ad Off il valore di default della direttiva di configurazione register_globals (nel file php.ini). Nulla di irreparabile, quindi; esiste, al contrario, un modo banale per ripristinare la situazione precedente, e cioè modificare il file php.ini e reimpostare la direttiva register_globals ad Off.

I prodromi di questo cambiamento si erano ravvisati già con l'introduzione, nella precedente release 4.1.0, di alcuni nuovi array associativi ($_GET, $_POST, $_SERVER, etc.) in luogo di altri ($HTTP_GET_VARS, $HTTP_POST_VARS, $SERVER_VARS, etc.), dichiarati contestualmente deprecati.

Le ragioni del cambiamento vanno ricercate nel tentativo di obbligare gli sviluppatori ad uno stile di programmazione meno esposto a rischi di sicurezza. In molte situazioni, infatti, la registrazione automatica delle variabili esterne come variabili globali può aprire delle falle di sicurezza negli script PHP. Tipicamente, un utente malizioso potrebbe tentare di alternare il comportamento di uno script fornendo un input ad hoc.
47 Commenti alla Notizia Latoserver.it/ PHP 4.2.0, una piccola svolta
Ordina
  • Scusate, ma proprio non capisco perchè utilizzare gli array aumenta la sicurezza... il problema del passaggio arbitrario delle variabili mi sembra che rimarrà comunque...

    Cambia il modo di accedere al file, non il modo di proteggerlo o di passarlo tra una pagina e l'altra....

    http://server.com/pagina.php?nome=pippo

    prima accedevo con $pippo, ora con $_GET["pippo"]
    qual'è la differenza per quanto riguarda la sicurezza? un utente malizioso può ancora impostare le variabili a suo piacimento, perciò, la differenza dov'è per lui?

    Ciao
    non+autenticato


  • - Scritto da: Killer of Daemons

    [CUT]

    > prima accedevo con $pippo, ora con
    > $_GET["pippo"]
    > qual'è la differenza per quanto riguarda la
    > sicurezza? un utente malizioso può ancora
    > impostare le variabili a suo piacimento,
    > perciò, la differenza dov'è per lui?
    >
    > Ciao

    credo, ma non ne sono sicuro, che se passi in POST o in GET un array chiamato _POST, il protocollo HTTP si incaxxi... non ho provato cmq.

    Ciao!
    non+autenticato
  • credevo avessero implementato il pattern MVC o un sistema di taglib per evitare di avere tutto quel ciarpame nelle povere pagine HTML, un metodo per rendere il codice scalabile... Il PHP restera' sempre e solo un linguaggio di scripting per dilettanti e per chi vuol giocare con le paginette senza saper nulla o quasi di programmazione.
    Divertitevi pure ma ad un certo punto migrate come o fatto io verso altri lidi...


    non+autenticato


  • > migrate come o fatto io verso altri lidi...

    Quali ad esempio?
    non+autenticato

  • > > migrate come o fatto io verso altri
    > lidi...
    >
    > Quali ad esempio?

    J2EE
    .Net

    ciao
    non+autenticato


  • - Scritto da: maks

    >
    > J2EE
    > .Net


    Motivo? cos'è che hanno di piu J2EE o l'architettura .net dal punto di vista della programmazione?
    non+autenticato


  • - Scritto da: DarKStaR
    >
    >
    > - Scritto da: maks
    >
    > >
    > > J2EE
    > > .Net
    >
    >
    > Motivo? cos'è che hanno di piu J2EE o
    > l'architettura .net dal punto di vista della
    > programmazione?

    L'architettura
    non+autenticato
  • cioè? spiegati meglio, per favore.... sembra un'interrogazione ad un ragazzino di 14anni che non sa un cazzo...

    come dicono i prof di tutto il mondo "devo tirarti fuori le cose con le pinze?"
    non+autenticato
  • be' in effetti il fatto che non sia tipizzato
    sega le gambe ad un po di costrutti tipici OO.
    (overloading etc)
    io non so che sia taglib , ma per quanto mi concerne
    nelle pagine php che faccio non   c'e' HTML..
    phphtmllib e un "package" che modella tag html.
    ..poi e' interpretato e OO spinta mi sembra che rallenti molto le prestazioni.
    ne convenite?
    non+autenticato
  • "Da un punto di vista pratico questa piccola svolta consiste nel modificare da On ad Off il valore di default della direttiva di configurazione register_globals (nel file php.ini). Nulla di irreparabile, quindi; esiste, al contrario, un modo banale per ripristinare la situazione precedente, e cioè modificare il file php.ini e reimpostare la direttiva register_globals ad Off."

    register_globals=ON => Funziona come prima

    register_globals=OFF => Nuove Regole accesso variabili.

    il default in 4.2.0 è register_globals=OFF
    non+autenticato
  • Nell'articolo si crea un malinteso sulla definizione di variabile globale: con il register_globals a on le variabili passate (in GET, POST, ecc.) non sono globali, ma disponibili nello scope dello script.
    Una variabile e' globale se definita tale con il costrutto global all'interno di una funzione o se e' inserita nell'array $GLOBALS.
    non+autenticato
  • Permettimi qualche precisazione:

    1) una variabile è globale quando è definita nello scope (= ambito di visibilità) globale

    2) l'uso della parola chiave 'global' all'interno di una funzione serve proprio a segnalare all'interprete PHP che per accedere ad una determinata variabile deve consultare il "global scope" e non quello locale alla funzione

    3) la direttiva 'register_globals', se attivata, fa sì che il processore PHP registri come variabili globali (inserendole quindi nel "global scope") quelle provenienti dal richieste GET/POST, cookies, etc.

    4) Per una variabile $var essere globale è equivalente all'essere registrata in $GLOBALS["var"]

    5) $GLOBALS, $_GET, etc. sono accessibili in qualsiasi contesto e sono pertanto definiti "superglobals"

    Spero di aver chiarito eventuali dubbiSorride
    non+autenticato
  • > 3) la direttiva 'register_globals', se
    > attivata, fa sì che il processore PHP
    > registri come variabili globali (inserendole
    > quindi nel "global scope") quelle
    > provenienti dal richieste GET/POST, cookies,
    > etc.

    Con la direttiva su on le variabili passate in GET ecc. non sono globali (non sono utilizzabili nelle funzioni a meno di non dichiararle esplicitamente tramite il costrutto global).
    non+autenticato
  • E' stato un passo obbligato per un linguaggio per alzarsi di livello e rendere il tutto più flessibile, così da allontanarsi dall'area dei linguaggi "semplici" quali ColdFusion & company. E quindi scatenare le sue potenzialità per sistemi più complessi in cui la gestione delle variabili non è affatto scontata !
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 7 discussioni)