Carrellata di risposte in arrivo
simonebortolin Legacy anche perché non vengono utilizzati i comuni sistemi CI/CD ma semplicemente un caricamento via FTP o simili (in realtà si può usare Heroku e fare un PHP legacy CI/CD). Non è da confondere con la modalità con framework come Laravel che fa in modo di lavorare come fosse un ambiente più simile a quelli esistenti come Node.js, e simili, ma che non analizzerò per due motivi: la percentuale d'uso di queste tecnologie è bassa.
Questo dipende solo ed esclusivamente dall'organizzazione del team, si può fare benissimo CI e CD anche con PHP.
Ed ecco a cosa serve la validazione degli input, usare le directory corrette ed escapare le stringhe.
simonebortolin non permette di elaborare i dati post in formato json.²
json_decode, json_encode
No(?), se il developer è una scimmia non è un problema del linguaggio.
simonebortolin il routing³ permette di accedere al file conn.php senza grossi problemi
Ti ricordo che tutto quello messo tra i tag di php non viene MAI inviato al client, salvo l'esplicito uso di un print o una configurazione errata del webserver.
Ad ogni modo, in un sistema decente, i file di configurazione non sono esposti al mondo, quindi magari invece di importare "./conn.php" importi "../conn.php", dove ../ è una directory non pubblica.
simonebortolin inoltre si ha per esempio user.php, login.php: è possibile che uno di questi file ci ha una versione non aggiornata di qualche controllo rendendo pericolosa la sicurezza
Penso di non aver capito ciò che volevi dire
simonebortolin PHP legacy di default mette come output il mime-type dell’html, qualsiasi altro mime-type deve essere specificato⁴, PHP legacy ha pochi controlli su user agent, cookie, e tantissimi header che vengono comunemente usati da anche Laravel in PHP.
Eh beh, di sicuro i mime types non se li può inventare.
Inoltre è possibile cambiare il default type.
La gestione di cookies, user agent e header è perfettamente fattibile anche su php stock.
simonebortolin questo richiede normalmente un invio di messaggi di tipo json o xml
Please don't.
Usare xml nel 2021 andrebbe evitato.
simonebortolin (il principale problema che ho riscontrato nell’usare Json in PHP è quello che basta uno spazio all’inizio o alla fine ed il Json non è più valido)
La pulizia degli input esiste per un motivo.
Inoltre se hai generato un json spero tu abbia usato funzioni apposite, e non roba del tipo "{" + key + "\":\"" + type + "\"}", dunque il famoso "spazio in più" non dovrebbe esistere, e se dovesse esistere, il tuo problema è ben differente.
simonebortolin spesso è necessario avere funzionamenti diversi a seconda di GET o POST
$_SERVER['REQUEST_METHOD'] esiste per un motivo.
Bastano 30 secondi su stackoverflow per trovarlo e ti dirò di più, la risposta ha oltre 10 anni.
simonebortolin PHP 5.0 era molto insicuro e pieno di bachi, ma almeno era veloce
Ti correggo: PHP5.x era insicuro, pieno di bug e lento come la morte.
Ceeerto, non è che le aziende non vogliono investire nell'aggiornamento della loro roba "perché tanto funziona" (poi si trovano un backup non programmato su qualche sito di hackeroonies e piangono).
Tralasciando che la sicurezza al costo della velocità dovrebbe essere sempre preferita, PHP7+ garantisce velocità e sicurezza migliori di PHP5.
Se per scartato da tutti gli sviluppatori intendi "non disponibile tramite apt scrivendo un comando perché quello sappiamo fare e se le cose diventano mezzo secondo più lunghe fa tutto schifo" devo darti ragione, altrimenti beh, sbagli sui dati anche qui.
simonebortolin Se invece vuoi fare un built-in devi perdere tempo in configurazioni di apache o nginx, fmp, php, sia in ambiente di sviluppo che in produzione.
Ed ecco come siamo arrivati alla gente che usa i webserver "di debug" in produzione.
simonebortolin Senza dimenticare l’annoso problema che PHP non usa Unicode, come viene usato da Java, Python, Node.js: in PHP è difficile far pace con i simboli di carattere non supportato, cioè che il principale problema di PHP è se stesso: l’architettura è nata errata negli anni 90, ed ora ci dobbiamo adeguare a questo.
Basta cambiare un'impostazione per sistemare tutto, non è difficile da fare.
Senza contare che ci sono migliaia di funzioni per gestire unicode su php.
simonebortolin Aggiungo anche una ultimissima cosa: integrazione con gli IDE: so che c’è una eterna diatriba tra programmare su terminale con vi(m) o programmare su IDE o su programmi di coding leggero: mentre i primi 2 sono molto orientati a fare operazioni di debug e compilazione tutto su terminale, il terzo usa un ambiente completo che ti fa tutto.
In realtà l'ambiente completo che "ti fa tutto" *ensomma* è l'ide, non il text editor.
simonebortolin Mescolando PHP e HTML si potrebbe pensare pure di generare CSS e JS custom in base a cosa genera il PHP: questa è una bad pratices perché il codice sarebbe molto più soggetto a SQL Injection.
"Se mischi benzina e gasolio ti si hackera la centralina"
è roba che non c'entra assolutamente nulla, sicuramente non è una buona soluzione per le performance, ma in che modo dovrebbe portarti alla sql injection?
Senza contare che esistono gli escape, per tutto, ed anzi, esistono pure i prepared statements, va te.
simonebortolin Concludo dicendo: che fare progetti in PHP nel 2021 senza nessun framework in maniera liscia standard non ha senso, tutto il resto si potrebbe fare perché comunque PHP è un buon linguaggio ma ha senso usare un linguaggio morto, ovviamente è preferibile usare altre strade
Ti sei contraddetto da solo.
simonebortolin in una applicazione bancaria è necessario essere sicuri che uno non possa inviare soldi via una richiesta GET
E perché mai? Se il mio programma sa gestirla non ho problemi.
Potenzialmente potrei far funzionare tutto a richieste DELETE, non sarebbe standard, ovvio, ma se sia il client che il server sanno come gestirsi la roba, funzionerebbe perfettamente.
simonebortolin Se ci dimentichiamo di specificarlo succede che un output di tipo json viene stampato con un times new roman.
Perché viene passato come HTML e quindi i browser applicano lo stile di default, non è PHP che si fa una copia del font e la gira all'utente tanto per simpatia.
[cancellato] E allora per quali altri utilizzi dovrebbe andare bene?
simonebortolin essere sicuro che non c'è nessun echo né prima né dopo di spazi altrimenti si corrompe
Non è che si corrompe, se aggiungi roba non è più un json, dunque, giustamente, non viene interpretato.
Metti un print sulla pagina prima del respondJSON da te citato e fammi sapere cosa succede.
File? quale file
simonebortolin no puoi fare if(isset($_POST)) ma se il post è vuoto non funziona (anzi il comportamento non è definito, per questo si mette come minimo un hidden o sumbit) e non puoi verificare PUT, GET, DELETE e tutti gli altri
$_SERVER['REQUEST_METHOD']
simonebortolin Si può dire che l'elaborazione PHP 7.0 è più veloce della 5.0 ma non il tempo di esecuzione di uno script PHP.
In generale è più lento, poi fare un while(i<1000) i++ è più veloce.
Mi sa che dovresti cercarti dei benchmark decenti
uadopo Evidentemente gli piace fare schifo
handymenny Vuoi dire che una singola esecuzione di uno script è più lenta in php 7 (e successivi) ?
Mi sembra impossibile, data l'introduzione di sistemi di caching sempre migliori e altre varie migliorie per sistemare eventuali problemi di performance.
[cancellato] Pessima scelta soldato, pessima scelta
simonebortolin Beh Wordpress usa questo design e fare tanti file su PHP è un problema di sicurezza
HO BISOGNO DI UN PO' DI VARECHINA PER I MIEI OCCHI.
Come dovrebbero essere dei file, esattamente funzionanti nello stesso identico modo, un problema di sicurezza?
Tralasciando che metterei le mani al collo di chi usa apache e non nginx, non è un problema di PHP se tu lasci accesso a roba sbagliata, sarebbe come prendersela con PHP se metti la stringa di connessione in un echo e lui non dovesse avere una super AI per detectare il tuo errore ed evitare di farti leakare le credenziali di accesso.
simonebortolin Sì, l'esecuzione di una singola istruzione è più veloce, l'esecuzione di un intero script compreso l'avvio dell'interprete php è più lento
Guarda, sono piuttosto sicuro del contrario, riesci a dimostrarmelo in qualche modo oggettivo?
Certo che se usi roba del genere te lo meriti di farti bucare.
Ma usare pdo fa schifo a tutti? Vi state complicando la vita per poi lamentarvi delle vostre pessime decisioni.
simonebortolin le query parametriche quelle con il ? secondo l'attuale letteratura sono da EVITARE in favore di:
WTF
Spero tu sia ironico, perché hai appena smontato tutto il web e anni di web development.
Ah sì, pure youtube le usa, direi che zio google non è proprio il primo pirla dietro l'angolo.
Ed ecco a cosa servono gli ide e i test prima di mandare in produzione.
Se tu sbagli non puoi prendertela con il linguaggio.
simonebortolin che su pluto_get.php?value non ho fatto il filtro perché tanto è un valore passato da javascript sai quanto è difficile da testare questo codice
Se non hai fatto la sanificazione dell'input o ancor peggio non hai usato i prepared statements il problema sei tu, non PHP.
È grazie alla gente che ragiona in questo modo se poi ci troviamo dump come quello di homobile.
simonebortolin in php è completamente diverso: un file php è visto come un file dentro la cartella pubblic e l'unico modo per inibire l'accesso è usare htaccess.
coff coff, dovresti settare la directory del webserver ad un livello più alto
uadopo Ho lavorato il PHP da autodidatta diversi anni fa ma posso assicurare che la forte tipizzazione e pattern in ambiente .NET lo rende molto più manutenibile e se si cambia azienda tendenzialmente non è un dramma lavorare sul codice di altri
Tralasciando che da quanto posso vedere sempre più aziende vogliono allontanarsi da .net, PHP supporta la tipizzazione, ovvio, non è un linguaggio a tipizzazione statica, ma i tipi esistono, come esistono le classi.
handymenny In PHP lo decidi tu, sono previste entrambe le modalità. Da quello che ho capito, si preferisce farle compilare al DB perché è più sicuro
Ci sono almeno due tipi di approccio differenti:
- Escape della query lato client -> Funziona, ma poi si rischia di finire come zoom, meglio evitare.
- Prepared statements -> Il client comunica al db la query che si andrà a fare, ma senza i dati.
Dunque il server sa già cosa aspettarsi, ha già fatto le sue ottimizzazioni e così via, semplicemente gli si passano i dati e se gli arriva un DROP dentro una stringa, non verrà eseguito, in quanto lui già sa qual è la query da eseguire e dove vanno i suoi parametri.
[cancellato] comincia a metterci una barriera in più invece di sperare che la libreria di sanitizzazione degli input scaricata da qualche repository
Esattamente, ma soprattutto, ti garantisce che nessuno vada ad eseguire queries non scritte da te.
Senza contare che con sta roba si possono richiamare tante volte le stesse query cambiando solo i dati.
simonebortolin dovuta a varie influenze sul fatto di ridurre al minimo i Prepared statement (e la cosa bella che sento spesso parlare di questo da tante persone, anche autorevoli)
Citamene una perché è ridicolo
Ovvio che sono complicazioni di affari semplici, come lo è passare per tutti i sistemi di sicurezza della banca.
Tutti i clienti son contenti di non avere scanner e roba varia, fino a quando non entra uno con un ak47 e pessime intenzioni.
[cancellato] Webassembly serve esattamente togliere di mezzo Javascript
In realtà no, visto che wasm ha comunque bisogno di js per funzionare.
Serve a sostituirlo solo per la roba pesante che esso stesso non sarebbe in grado di gestire.
Technetium Qualsiasi linguaggio è portato allo sviluppo web, non c'è un migliore, soprattutto nella direzione che si sta prendendo, ovvero quella di dare API e non direttamente del contenuto.
Devi appunto vedere con cosa gira meglio il backend ed adattare le API ad esso, non il contrario.
