LucaTheHacker Questo dipende solo ed esclusivamente dall'organizzazione del team, si può fare benissimo CI e CD anche con PHP.
Ovviamente tutto si può fare, solamente che in altri linguaggi è più facile.
LucaTheHacker Ed ecco a cosa serve la validazione degli input, usare le directory corrette ed escapare le stringhe.
LucaTheHacker La pulizia degli input esiste per un motivo.
Sono d'accordo
LucaTheHacker json_decode, json_encode
LucaTheHacker 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.
LucaTheHacker 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.
LucaTheHacker 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.
Come già detto e come ho specificato nella nota: json_decode, json_encode ci sono, ma il problema che ho sottolineato io, ovviamente ho già più che specificato che la cosa che è macchinosa è parsare un JSON passato in POST. Come già detto il problema di PHP secondo me è quello che by default l'ouput è un HTML.
Ovviamente si si può anche fare una print prima del respondeJSON e quindi si bugga tutto, però ripeto, in PHP uno spazio ti può scappare, in altri linguaggi no.
LucaTheHacker No(?), se il developer è una scimmia non è un problema del linguaggio.
LucaTheHacker 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.
Dipende dal suo know how semplicemente è questo. Il programmatore php comune non sa tutto questo. E mette tutto in cartelle simili, è raro pure che sappia giocare con con htdocs.
LucaTheHacker Penso di non aver capito ciò che volevi dire
è semplice: in un file che c'è un check obsoleto o assente
LucaTheHacker 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.LucaTheHacker $_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.
Si ma in altri linguaggi REST oriented è molto più facile, ovviamente è più facile dire si può fare tutto in PHP
LucaTheHacker Please don't.
Usare xml nel 2021 andrebbe evitato.
Si vede che non hai mai lavorato in un ambiente dove XML è stra usato e non è che si può migrare in JSON da un girono all'altro. Ovviamente è sempre la stessa storia XML è legacy, JSON è attuale. Ma ci sono sistemi che usano XML e vanno mantenuti. Non si può dire così.
LucaTheHacker Ti correggo: PHP5.x era insicuro, pieno di bug e lento come la morte.
Si vede che non hai mai lavorato in un ambiente reale. Come già detto e spiegato e come è facile leggere online PHP5 è più veloce di PHP7 nell'esecuzione di uno script in media, PHP7 è più veloce nell'esecuzione di una singola istruzione in quanto ci sono vari sistemi di coaching e simili, ma questi sistemi devono essere caricati e rallentano l'esecuzione.
LucaTheHacker 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 scrivi PHP7.4+ sono d'accordo.
LucaTheHacker 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.
PHP 7.0 ha avuto un insuccesso tale da far abbandonare numerosi member del core team, ovviamente si sono io quello che sbaglia sui dati, al 2018 c'erano più istanze PHP 5.0 che PHP 7.X
LucaTheHacker Ed ecco come siamo arrivati alla gente che usa i webserver "di debug" in produzione.
è sempre stato così, e lo sarà sempre
LucaTheHacker Basta cambiare un'impostazione per sistemare tutto, non è difficile da fare.
Senza contare che ci sono migliaia di funzioni per gestire unicode su php.
i programmatori PHP non sono in pace con Unicode, e ed sarà sempre Così. PHP usa la gestione di stringe del C/C++ a caratteri di 8 byte, senza supporto a Unicode. Inoltre non è così semplice come affermi. So perfettamente che è fattibile, ma non è semplice.
LucaTheHacker In realtà l'ambiente completo che "ti fa tutto" ensomma è l'ide, non il text editor.
è un errore di scrittura. Grazie.
LucaTheHacker "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.
Come già detto, più si mischia le robe più è facile fare bachi. E si che il tuo username faceva riferimento a questo. Secondo te perché si cercano falle di tipo SQL Injection o XSS? Perché essendo un miscuglio tra più linguaggi è più facile trovare bachi.
Perché si cerca falle nelle API? Perché essendo una comunicazione client-server è più facile trovare bachi.
Perché si cerca falle nelle interazioni tra due sistemi? Perché è più facile cercare falle ove due cose interagiscono e non all'interno di un codice?
LucaTheHacker Ti sei contraddetto da solo.
Evidentemente non hai colto ciò che ho affermato
LucaTheHacker 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.
Perché semplicemente i dati vengono trasmessi in url encoding sull'url e se per caso uno chiama questa funzione rischia di fare danni, proprio per questo in applicazioni bancarie si usa tutte richieste di POST.
E si che non ci vuole poco a capire un concetto simile
Se la tua home banking ha una api del genere: api.homebanking.it\transfermoney?to=simone&soldi=1000.00&codecheck=OTP&tok=1858438377858548
Un attacco XSS per esempio tramite il famosissimo loading di immagine sai quanto è semplice? E si che è la roba più banale della terra.
LucaTheHacker File? quale file
Questo file: php://input, quello per leggere il post in RAW
LucaTheHacker Mi sa che dovresti cercarti dei benchmark decenti
Cercali pure TU se non ti fidi. Ci sarà un motivo se grandi big hanno fatto propri motori di rendering PHP.
LucaTheHacker Guarda, sono piuttosto sicuro del contrario, riesci a dimostrarmelo in qualche modo oggettivo?
Oltre alle fonti che ho già messo? Non ho problemi a fare dei test, ma non credo che cambierai idea.
LucaTheHacker Mi sembra impossibile, data l'introduzione di sistemi di caching sempre migliori e altre varie migliorie per sistemare eventuali problemi di performance.
è così, è risaputo.
LucaTheHacker Pessima scelta soldato, pessima scelta
Che simpatico.
LucaTheHacker 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?
Sai quante falle ci sono negli script di plugin wordpress messi nelle cartelle \wp-admin\script?
Lo sai?
Lo sai?
Considera che ogni giorno c'è né una nuova su https://owasp.org/
LucaTheHacker 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.
Su altri linguaggi non c'è proprio la possibilità di queste configurazioni errate. è questo il punto, ma ovviamente non è chiaro.
LucaTheHacker 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.LucaTheHacker 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.LucaTheHacker Citamene una perché è ridicolo
LucaTheHacker 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.
C'è già stato un grosso discorso su questo argomento, ovviamente io conosco i vantaggi e ho compreso tutte le motivazioni dietro all'uso di PDO, so anche che numerosi testi le sconsigliano in favore delle query semplici e dell'ORM. Infine ripeto io ho condiviso la mia esperienza decennale, e non ho intenzione di andare a scovare le fonti di ciò che ho letto 5 anni fa (perché non me le ricordo), e ripeto che lo ho sentito almeno 3 o 4 volte nella mia vita. Come già spiegato prima da @[cancellato] è una errata percezione, e ne sono d'accordo. Ciò non toglie che è la strategia più utilizzata.
LucaTheHacker Ed ecco a cosa servono gli ide e i test prima di mandare in produzione.
Se tu sbagli non puoi prendertela con il linguaggio.
Per fortuna
LucaTheHacker 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.
Concordo, ma il panorama è pieno di persone del genere.
LucaTheHacker 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.
Io invece vedo il contrario .NET core sta attirando tanta gente che usava java.
LucaTheHacker 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.
Grazie per l'ennesima precisazione.
[cancellato] Per esempio, grazie a questo thread ho capito i reali vantaggi di usare le prepared statement, cosa snobbata da tutti.
[cancellato] Anche un dibattito sulle differenze tra web server in termini di configurabilità, sicurezza, efficienza, etc etc... sarebbe interessante.
Quì rischiamo di andare troppo su idee personali e non oggettive.
Alfoele Sono tanti quelli che resistono "difensivissimi" sulle proprie posizioni, vuoi per dimensioni e conseguenti impatti della transizione, vuoi per costi, ecc..., mettendo pezze qua e là e tenendo in essere roba obsoleta ben oltre i tempi massimi del ciclo di vita di certe soluzioni...
Cioè che funziona non si tocca
dadadani tesso motivo per cui certi pos e simili eseguono versioni preistoriche di certi sistemi operativi.
come già detto prima il discorso è se dovessi essere costretto a scrivere in una piattaforma esistente legacy, ma cercherei in tutti i modi di convincere a fare il passaggio a qualcosa di moderno (esempio capita che si rompe qualcosa di esterno e proponi di riscrivere tutto).
Cioè che funziona non si tocca pt2.
matteocontrini PHP si può usare bene sfruttando framework e tecnologie adeguate, e non ha ad oggi molto da invidiare alla concorrenza. Basta scegliere di usarlo bene. Soluzioni come Laravel sono molto molto complete e ti costringono a scrivere codice bene e in OOP.
Concordo, e questo era la mia conclusione.
maverick82 Complimenti, hai trovato un posto dove si lavora bene.