[cancellato]
- Modificato
simonebortolin Tanterrima roba, ho fatto proprio bene a stimolare un tuo intervento articolato 
Programmare in PHP nel 2021 ha senso o no?
- Modificato
handymenny qui abbiamo un problema di design però
Ormai PHP è anche orientato agli oggetti, non ha nemmeno più tanto senso creare file da 100k righeHo capito cosa vuoi dire, è un po' macchinoso, però se uno separa le API JSON dal resto (o implementa il resto con altri linguaggi), direi che non è un problema così grosso
Beh Wordpress usa questo design e fare tanti file su PHP è un problema di sicurezza: guarda wordpress spesso le falle stanno nei file script.php dei vari plugin.
Supponi di fare tanti file piccoli c'è un grosso problema: tutti questi sono direttamente accessibili da www.miosito.it/businesslogic/file.php e questi sono una falla di sicurezza: potrei limitare l'accesso con htaccess, potrei fare tante robe: ma è un problema di design di php non mio.
E pure i framework soffrono degli stessi problemi.
handymenny Mi riferivo al REQUEST_METHOD che trovi qua: https://www.php.net/manual/en/reserved.variables.server.php
There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.
handymenny Vuoi dire che una singola esecuzione di uno script è più lenta in php 7 (e successivi) ?
Sì, l'esecuzione di una singola istruzione è più veloce, l'esecuzione di un intero script compreso l'avvio dell'interprete php è più lento
[cancellato] ed io che stavo aspettando che aprivi il topic, dopo un po' mi sono stufato di aspettare e lo ho aperto io.... Sto comunque apprezzando molto alcuni commenti altrui 
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.
cos
sono anni che non metto mano a php, ma generare contenuti dinamici non ha nulla a che vedere con l'sql injection, che tra l'altro si evita totalmente con le query parametrizzate (che una veloce ricerca mi indica chiamarsi prepared statements nel mondo php)
simonebortolin There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.
Questo perché dipende dal webserver che usi. PHP non fa da webserver quindi non ha modo di garantirti i dati che gli passerà il tuo webserver
simonebortolin Supponi di fare tanti file piccoli c'è un grosso problema: tutti questi sono direttamente accessibili da www.miosito.it/businesslogic/file.php e questi sono una falla di sicurezza: potrei limitare l'accesso con htaccess, potrei fare tante robe: ma è un problema di design di php non mio.
Di solito è buona prassi separare nettamente (cioè mettere in cartelle diverse) ciò che è accessibile pubblicamente dal resto, ma questo l'ho visto fare a prescindere dalla tecnologia utilizzata.
[cancellato]
[cancellato] le applicazioni web continuano a fare schifo, e anzi peggiorano da quando sono diventate "mobile first" - cioè vanno usate con un dito.
OT nell'OT... Nì, non sempre. Diventano sempre più pesanti, e per certi aspetti la moda di fare webapp invece che client standalone è assolutamente deleteria, ma per molti altri aspetti ti eviti un mare di complicazioni lato client, e te le rende usabili anche dove l'installazione di software sui terminali non è possibile.
Poi spesso la colpa è più dei designer, e di chi pone requisiti di essere responsive e mobile first dove non ha assolutamente senso se non perché va di moda (seriamente, un gestionale su smartphone? Really???).
- Modificato
handymenny Braccoz le query parametriche non servono per evitare le sql injection, una query è già sicura con mysqli_real_escape_string se:
- usi charset comuni
- usi la versione con la connessione al db
- non ti fai passare come parametro nomi di colonne (N.B. PDO rifiuta proprio questo tipo di query)
le query parametriche quelle con il ? secondo l'attuale letteratura sono da EVITARE in favore di:
- query classiche con i valori passati come variabile filtrata
- query autogenerate dal codice in maniera invisibile per l'utente (Stile lambda/Linq/dsl/...)
in quanto aumentano in maniera "stupida" la complicazione della query. Si usano le PDO solamente nel caso in cui si lavora con colonne o tabelle passate come parametro
la insicurezza derivata a attivare/disattivare pezzi di codice javascript da PHP è ovvio supponiamo di avere questo uno script in cui si fa var paperino = < php echo $_GET["paperino"]; >(c'è clouflare che mi blocca i < ? senza spazio )
Supponiamo che per qualche motivo sulla variabile paperino ci sia uno script che sfrutta una vulnerabilità SQL Injection o XSS, e 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, questa vulnerabilità era tra le top 10 owasp 10 anni fa quando era pieno di script js generati da php
handymenny sono d'accordo: ma mentre qualsiasi framework basato su java/python/node ci ha una cartella pubblic dove ci metti le risorse statiche, tutto il resto viene generato dallo script
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.
simonebortolin le query parametriche non servono per evitare le sql injection, una query è già sicura con mysqli_real_escape_string se
"se"
e' quel se su cui si basano le sql injection.
simonebortolin le query parametriche quelle con il ? secondo l'attuale letteratura sono da EVITARE in favore di:
cos
vabe, mi eietto dal thread
[cancellato]
- Modificato
simonebortolin ed io che stavo aspettando che aprivi il topic, dopo un po' mi sono stufato di aspettare e lo ho aperto io.... Sto comunque apprezzando molto alcuni commenti altrui
Non vivo mica sul forum 
e per fortuna hai avviata la discussione perché si sta rivelando proprio interessante!
[cancellato] Poi ogni linguaggio ha un campo di applicazione dove è meglio di altri - poi c'è chi sceglie il linguaggio in base a quanto costano poco gli sviluppatori (e si vede).
WordPress che io sappia rimane in PHP - e rimane uno dei CMS più diffusi. Applicazioni che hanno backend più complessi e con specifici requisiti - spesso di interazione con altre applicazioni - possono beneficiare dall'usare altri linguaggi. In certi ambienti ad esempio fa comodo usare gli application server Java come Tomcat o JBoss. Chi ha a che fare con tecnlogie MS ha sicuramente la vita più facile in .NET.
Confermo. 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
[cancellato]
- Modificato
simonebortolin le query parametriche quelle con il ? secondo l'attuale letteratura sono da EVITARE in favore di:
query classiche con i valori passati come variabile filtrata
query autogenerate dal codice in maniera invisibile per l'utentein quanto aumentano in maniera "stupida" la complicazione della query
Cultura alimentata da chi con i database non ci ha mai lavorato in vita sua, e non ha mai capito come lavora il query planner. Riusare una stessa query con valori parametrici diversi significa ripescare direttamente dalla cache la migliore strategia di accesso al dato senza rifare l'analisi.
Involuzione informatica.
Sì, mi stanno abbondantemente sui $gioielli Hibernate e simili, e soprattutto le loro mer(d)avigliose query autogenerate illeggibili ed inutilmente prolisse perché per pigrizia recuperano tutti i campi degli "oggetti" che non servono, o fanno 3000 query per il lazy loading, quando basterebbe sapere cosa si vuole ottenere fin dal principio (ma implica essere capaci a programmare e a fare analisi, cosa non scontata).
- Modificato
Braccoz il tuo parere è gradito, non eittarti.
[cancellato] Cultura alimentata da chi con i database non ci ha mai lavorato in vita sua, e non ha mai capito come lavora il query planner. Riusare una stessa query con valori parametrici diversi significa ripescare direttamente dalla cache la migliore strategia di accesso al dato senza rifare l'analisi.
Involuzione informatica.
Ma scusa l'uso di query fatte attraverso comandi domain-specific languages (per esempio le LINQ di C#, o più in generare le funzioni lambda) per effettuare le query non è simile a quello delle query parametriche?
In quando mi sembra che la query PDO prima di essere inviata al DB viene compilata e trasformata in SQL.
Inoltre il query planner non dovrebbe essere sensibile ai parametri, e il risultato sarebbe simile a quello delle query "classiche" in quanto tutte le query arrivano al DB come stringa. Soprattutto per il fatto che non c'è una sintassi comune tra i vari linguaggi ma ognuno fa a sé (alcuni ? altri @nome, ...)
Infine inoltre le Prepared statement non proteggono da attacchi XSS né da attacchi SQL di seconda specie a Trigger o simili, quindi l'input deve essere sempre filtrato a priori.
Però forse ho capito: intendi che basta che sia un parametro che cambia ed il query planner non fa l'analisi?
[cancellato] Sì, mi stanno abbondantemente sui $gioielli Hibernate e simili, e soprattutto le loro mer(d)avigliose query autogenerate illeggibili ed inutilmente prolisse perché per pigrizia recuperano tutti i campi degli "oggetti" che non servono, o fanno 3000 query per il lazy loading, quando basterebbe sapere cosa si vuole ottenere fin dal principio (ma implica essere capaci a programmare e a fare analisi, cosa non scontata).
Sul fatto che ci siano strumenti come l'Hibernate che sono un ufficio complicazioni delle query sono d'accordo, ma non tutti gli strumenti di generazione query via funzioni/dsl sono così
- Modificato
only4midi
e chi è il furbone che ha commissionato i lavori in php ad uno sviluppatore che lavorava su .net ?
Proprio vero che certe aziende proprio non curano proprio come spendono.
Non ce l'ho con te eh.. ci mancherebbe ! Anzi.. sono contento per voi.
Però vedo spesso tanto pressapochismo in certi ruoli aziendali che fa paura.. ma prendete dei consulenti no ?
simonebortolin In quando mi sembra che la query PDO prima di essere inviata al DB viene compilata e trasformata in SQL.
In PHP lo decidi tu, sono previste entrambe le modalità. Da quello che ho capito, si preferisce farle compilare al DB perché è più sicuro
- Modificato
handymenny Io avevo letto che in PDO c'era un ambiente virtuale di test delle query che fa da compilazione e sanificazione, però se è così meglio. Magari andrò a leggere bene tutto il funzionamento di PDO, più che altro non sapevo che un DMBS aveva API del genere.
[cancellato]
simonebortolin In quando mi sembra che la query PDO prima di essere inviata al DB viene compilata e trasformata in SQL.
Il problema è proprio quello. Una query parametrica per di più "prepared" non deve essere riparsata, l'engine DB l'ha già bella e pronta per l'esecuzione - sono comunque più sono molto più robuste alla SQL Injection - defense in depth, comincia a metterci una barriera in più invece di sperare che la libreria di sanitizzazione degli input scaricata da qualche repository e scritta da un Elboniano nel tempo perso non abbia bug.
Cambiare ogni volta la query non sfrutta questa capacità. Per query "una tantum" cambia poco e può a volte anche essere più efficiente - di solito in ambiente datawarehouse dove il plan è più sensibile ai parametri - ma più spesso in ambiente OLTP è dannoso - e non è che un DB moderno ignora il valore dei parametri - di solito ormai fra le statistiche ha anche la distribuzione dei dati e vede se un parametro è "borderline".
Il problema è che ci sono due modi per usare un database - il primo è il "data dump" - la "discarica dei dati" dove lo usi in pratica solo come storage, il secondo è usarlo come un rdbMS - con l'accento su Management System - dove sftutti le capacità del sistema di elaborare in proprio - e di solito in maniera molto efficiente purché usati come richiesto - molto meno portabile, ma spesso molto più efficiente - in particolare se usi database che hanno capacità elevate di elaborazione.
Parlo di database relazionali perché se parliamo di SQL escludo altri tipi.
[cancellato]
Technetium Si è stra superato a livello enterprise poi certo se fai siti in drupal per i negozietti di quartiere è ancora la scelta migliore forse, come detto è una tecnologia superata ad oggi, ma va ancora bene per alcuni usi.
[cancellato]
simonebortolin Sul fatto che ci siano strumenti come l'Hibernate che sono un ufficio complicazioni delle query sono d'accordo, ma non tutti gli strumenti di generazione query via funzioni/dsl sono così
Questo lo dice chi non sa programmare ad oggetti e non conosce il paradigma di Hibernate, ovvio che se non lo conosci e pensi ancora a query è ovvio che ti risulti complicato.
Poi come sempre tutte le tecnologie hanno i pro e i contro come per tutto.
[cancellato]
- Modificato
simonebortolin Inoltre il query planner non dovrebbe essere sensibile ai parametri,
Non lo è infatti, ma al testo scritto sì.
E se il linguaggio traduce SELECT * FROM prezzi WHERE item = "mela"; e SELECT * FROM prezzi WHERE item = "pera"; in due stringhe diverse invece che (SELECT * FROM prezzi WHERE item = ?;, "mela") e (SELECT * FROM prezzi WHERE item = ?;, "pera") , per il query planner sono due query diverse, e deve ricominciare l'analisi. Magari si ferma ad estrarre i literali e a renderla internamente pseudo-parametrica, ma è sempre lavoro in più che deve fare quando può comparare un hash di una stringa e accorgersi che, toh, ce l'ho già.
simonebortolin l'input deve essere sempre filtrato a priori.
Non ho mai detto che non si debba fare o che servano a questo però
[cancellato] Conosco flotte di DBA (sic!) strenui sostenitori de "la coerenza relazionale deve essere garantita dall'applicazione" e che non mettono foreign key perché gli ostacolano i backup/restore (non hanno capito che basta sospenderle o eliminarle e ricrearle, in caso estremo...) e il loro modo di creare gli oggetti (per certa gente per dire è """normale""" che esistano prima le righe fattura della testata)... poi si chiedono perché sono sempre nervoso...
- Modificato
simonebortolin Io avevo letto che in PDO c'era un ambiente virtuale di test delle query che fa da compilazione e sanificazione, però se è così meglio.
si tratta del flag: PDO::ATTR_EMULATE_PREPARES
Apprendo dal web, che mentre per MySQL l'emulazione è attiva di default per motivi di compatibilità con vecchie versioni di MySQL, con DBMS più "avanzati" come Postgresql è disattiva di default
- Modificato
[cancellato] però in ambito datawarehouse non ci dovrebbe essere bisogno di filtrare le query o sbaglio? Non ci dovrebbe essere input dell'utente malefico, e quindi in quel caso query preparate hanno senso, inoltre non credo neanche che si usi PHP in ambito DW.
[cancellato] Premetto che di Hibernate ho solo visto codice scritto da altri per vari motivi non ho mai approfondito più di tanto, ma essendo un ORM come tanti altri più o meno complessi (da Android Room, Realm (però questo usa un paradigma abbastanza relazionale con un db non relazionale), ET- LINQ, jOOQ, ...) ho notato l'overload di codice spesso inutile dovuto oltre alla non conoscenza dell'architettura della libreria di ORM al linguaggio di programmazione.
[cancellato] Non lo è infatti, ma al testo scritto sì.
E se il linguaggio traduce SELECT * FROM prezzi WHERE item = "mela"; e SELECT * FROM prezzi WHERE item = "pera"; in due stringhe diverse invece che (SELECT * FROM prezzi WHERE item = ?;, "mela") e (SELECT * FROM prezzi WHERE item = ?;, "pera") , per il query planner sono due query diverse, e deve ricominciare l'analisi. Magari si ferma ad estrarre i literali e a renderla internamente pseudo-parametrica, ma è sempre lavoro in più che deve fare quando può comparare un hash di una stringa e accorgersi che, toh, ce l'ho già.
Si se viene mandato in SQL il ? sono d'accordo al 100% sulla maggiore efficienza (è evidente), ma la mia conoscenza sulle query, 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) in quanto a loro dire "sono una complicazioni affari semplici " (e si che lo trovi pure su alcuni libri di testo...) mi ha limitato le mie doti di investigatore mi ha fatto pensare veniva elaborata lato applicazione la query tramite l'ambiente virtuale appena citato da handymenny, d'altronde è sempre possibile fare un print della query buildata.
[cancellato] Non ho mai detto che non si debba fare o che servano a questo però
Il mio era un: è meglio sanificare una volta e darlo in pasto ad una query nuova che filtrare e poi usare i prepared statement, ma sono d'accordo sul fatto che ci sono motivi per usarlo.
[cancellato] Conosco flotte di DBA (sic!) strenui sostenitori de "la coerenza relazionale deve essere garantita dall'applicazione" e che non mettono foreign key perché gli ostacolano i backup/restore (non hanno capito che basta sospenderle o eliminarle e ricrearle, in caso estremo...) e il loro modo di creare gli oggetti (per certa gente per dire è """normale""" che esistano prima le righe fattura della testata)... poi si chiedono perché sono sempre nervoso...
Questo è il minimo dei DBA. Nessun DBA è in pace con i charset per esempio....
Chiedo al moderatore se il testo scritto (con ovviamente riferimenti a commenti ed annotazioni) sul forum lo posso riutilizzare su un blog personale e/o in altri posti (tipo appunti, ovviamente senza scopo di lucro) in quanto è una bella discussione, soprattutto la parte su PDO.