Ok, visto che in tanti ne hanno parlato, e visto che qualcuno ha finalmente detto ciò che andava detto:
Ecco i miei 5 cents per il nuovo, rivoluzionario, sistema di ridimensionamento immagini!!! (cose del 1999 e gd1 ... insomma)rainghio
a volte la semplicità o l'acqua calda diventa pericolosa quando gente che non la sa usare si trova davanti spesso a condizioni abbastanza pericolose, come un codice che presenta diverse "falle" e la usa senza sapere cosa fa ..
auguri per i doscodice:63. $memoryToAllocate = '100M';
ehr ... qualcuno mi spiega che razzo significa questa regexp?codice:68. $image = preg_replace('/^(s?f|ht)tps?:\/\/[^\/]+/i', '', (string) $_GET['image']);
'/^(s?f|ht)tps?:\/\/[^\/]+/i'
sono io a non capirla, o secondo l'autore esiste un url con protocollo tipo
sftps://-/
???
... se si, me lo spiegate? ... grazie!
Ammesso esista ... mi sorge in altro dubbio ... esiste un caso nel mondo dove un parametro GET o POST non sia una stringa?
Cosa diavolo significa (string) $_GET['image'] ?
Ve lo dico io, significa che l'autore dello script di PHP non sa una cippa
Prima perchè GET è sempre stringa, secondo perchè se passi una variabile ad una funzione che lavora con le stringhe, l'eventuale casting è fatto dalla funzione stessa.
Andiamo avanti ... da linea 70 a linea 93, abbiamo dei fantastici controlli che ci permettono di usare una banale /index.php, nella root del sito, come file di prova
Di li in poi chissà cosa succede ... succede che al limite, nella migliore delle ipotesi, ci sarà un errore ... grazie al fantastico controllo fatto poi ...
Ed ecco che comincia il magico resizing!
La width, come la height, possono essere negative, permettendoci di giocare con i risultati, massacrando di request in request, il server che ospita lo script.
Ma perchè sprecare energie quando di default i valori sono assurdi per conto loro?
Se non settiamo width ed height i valori saranno 99999999999999, una larghezza in pixel che supera addirittura il limite massimo di un integer 32 signed, sia questo il limite int di php, sia questo quello di Java o JS.
Un numero assurdo, per renderci conto, insupportabile da qualunque schermo ... ma l'autore sa qualcosa dei linguaggi di programmazione, o ha sparato grandi numeri a caso?
A no, ha pensato bene di cntrollare, con un altro assurdo cast in stirng ed una regexp, la presenza del parametro GET, color.
Bene, se lo settate, senza impostare width ed height ... lo script va avanti ...
Possiamo impostare un cropratio come ulteriore parametro ... ma anche no, ergo andiamo avanti.
La certezza assoluta che l'immagine sarà in qualche modo ridimensionata, l'abbiamo tramite le fantastiche $xRation ed $yRatio.
Queste si basano su una divisione, peccato la divisione sia in base a width ed height trovate grazie all'immagine tramite size[0] ed [1].
Cosa significa? ... significa che se per sbaglio avete un'immagine usata come delimitatore o altro, da 1 pixel di altezza, e la usate come immagine che verrà riconosciuta come valida,
il ridimensionamento finale sarà di 99999999999999 X 99999999999999
Qualunque cosa accada poi, è assolutamente ininfluente poichè abbiamo già tutti gli strumenti per far esplodere il server, e sono a meno di metà script
Ragazzi, non basta avere un blog per essere programmatori, bisogna avere esperienza, e parecchia skill (che richiede studi, e testing).
Ma soprattutto, vi prego, prima di pubblicare qualcunque cosa abbia a che fare con opzioni passate dal client, e vale anche per Ajax (vacca boia), pensateci mille mila volte, ne vale la vostra reputazione, poi è difficile da recuperare quando scrivete orrori esagerati.
A voi commenti, insulti, altro ... al solito
[edit] ... poi magari sono solo invidioso di aver prodotto ben più notevole codice, questi ultimi mesi, passato completamente in sordina ... scavalcato da paginelle piaccapì di questo calibro ... e va beh, lo ammetto, rosico quando leggo notizie inerenti progetti così mal concepiti ... non me ne vogliate
[edit2 la vendetta] ... anche io ho scritto orrori, e probabilmente ne scrivo tuttora, ma non sono mai stato pubblicizzato troppo per questi orrori, anzi ... questo post non è una critica verso una notizia che comunque sarebbe girata in rete comunque, è una critica al modo di sviluppare php che grazie all'insieme di questi progetti non è considerato un linguagio enterprise, nonostante gli sforzi della comunità. Dare accesso al server tramite valori client, è sempre un rischio, e ci sono dozzine di articoli inerenti la sicurezza server. daniele ha osservato anche altro, io non mi sono voluto spingere oltre (volevo fermarmi alla terza riga di codice ...). La programmazione è un mestiere ... come ci sono idraulici e meccanici di discutibilissima bravura / serietà, ci sono programmatori che non sono programmatori ... e in italia, purtroppo, ce ne sono tanti. Consiglio di documentarvi sempre sulle best practices e la sicurezza, nello stesso HTML.it ci sono ottimi e numerosi articoli per svariati linguaggio che parlano di problemi inerenti variabili ricevute dall'esterno, il client, o il malintenzionato di turno. Buon approfondimento a tutti, e scusate l'eccessiva passione in questo post.
Rispondi quotando
