Re: apache php e problemi nell' upload dei file

2023-05-19 Per discussione Leonardo Boselli

On Wed, 17 May 2023, Lorenzo Breda wrote:

Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 

 On Wed, 17 May 2023, Giuseppe Naponiello wrote:

(…)mi permette di costruire una piattaforma ben strutturata e con
interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue

Le interfacce fighe sono il sistema migliore per creare sistemi
instabili, esigenti di risorse e lente.


Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da
che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero (certo,
sono una cosa  in più da gestire, ma se si deve si deve), che richiedano
maggiori risorse dipende quali risorse. Di solito i sistemi per "interfacce
fighe" riducono di molto la necessità di risorse di rete mentre aumentano
la necessità di risorse di calcolo sul client. A volte è follia,
a volte è fondamentale. Basta sapere cosa si sta facendo e perché.


ed è giusto questo: di solito i limiti sono lato client o lato rete, lato 
server solo in certi casi, se davvero molto carichi o che necessitano di 
risposta in tempo quasi reale.
Ti faccio due esempi che supportano la mia opinione: Un sito che per 
rispondere a un messaggio, dove basterebbe un form con un campo txt e un 
paio di checkbox, se non li hai nella cache ti carica circa 1.7 MB di 
script che non fanno assolutamante nulla se non abilitare un editor che ti 
crea più problemi che vantaggi: mi trovo spesso in un luogo servito da un 
ripetitore locale (perché in zona d'ombra) che al massimo offre GPRS. il 
risultato è che caricando la pagina si ottine un timeout, rendendo 
impossibile l'accesso. un altro sito che fa le stesse cose, ma ottimizzato 
per light client funziona perfettamente e senza attese.
Altro sito "fancy": quando fai una ricerca  al terzo carattere ti mostra 
una lista di tutti i valori possibili. Bello, solo che se non appare nei 
primi 20 non hai la possibilità di andare oltre e devi continuare a 
scrivere senza suggerimenti sperando di beccare quello giusto, e quello 
che è peggio non ti dice se la lista è completa o non ce ne sono altri, di 
fatto nulla più che se avessi inserito alcuni caratteri e poi premuto 
"search" (in  quel caso te ne fa vedere 20, ma esplicitamente di dice se 
ce ne sono altri, invitandoti a aggiungere altri caratteri)



--
Leonardo Boselli
Firenze, Toscana, Europa

Re: apache php e problemi nell' upload dei file

2023-05-18 Per discussione Giuseppe Naponiello
Ok, giusto, allora chiedo scusa e faccio un mea culpa, diciamo allora 
che in ambito web php è ancora il più usato? Ovviamente non prendo in 
considerazioni webapp ibride.


Non ho scritto che non ci sono alternative ma che non ce ne sono tante, 
sinceramente ho sempre creduto che ASP.NET fosse ormai in disuso e che 
Java fosse troppo "avida di risorse", quindi non raccomandabile per 
progetti di piccola e media grandezza/complessità (almeno così me 
l'hanno sempre raccontata).


Comunque grazie davvero, è sempre bello ascoltare pareri diversi, impari 
sempre qualcosina in più...dai fino ad ora siamo stati bravi a non far 
degenerare la discussione!!! 😂


Il 17/05/23 17:16, Federico Di Gregorio ha scritto:



On 17/05/23 16:54, Giuseppe Naponiello wrote:
In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che 
se hai bisogno di PHP non puoi prescindere da librerie javascript, a 
meno di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti 
daccordo sul fatto che se vuoi una piattaforma web solida, complessa, 
sicura e robusta non ci sono tante alternative al nostro caro e 
vecchio php...si ok, c'è anche python ma non è fatto per quello, e 
lasciamo stare tutto ciò che ha a che fare con node ecc.


Dire che non ci sono alternative è veramente sbagliato. Diciamo che se 
parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo 
io, che supportino tutte le tecnologie moderne, dai websocket in su) 
ci sono almeno due alternative: Java (con tutte le sue varianti di 
librerie e framework) e C# (con ASP.NET Core). E ho preso solo le 2 
notissime.


federico





Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Lorenzo Breda
Il mer 17 mag 2023, 17:16 Federico Di Gregorio  ha scritto:

>
> Dire che non ci sono alternative è veramente sbagliato. Diciamo che se
> parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io,
> che supportino tutte le tecnologie moderne, dai websocket in su) ci sono
> almeno due alternative: Java (con tutte le sue varianti di librerie e
> framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime.
>

Esatto, Java soprattutto con Spring e C#, ma anche Swift non è da buttare
fatte le dovute considerazioni.

E non butterei alle ortiche Node.js, suvvia.

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Federico Di Gregorio




On 17/05/23 16:54, Giuseppe Naponiello wrote:
In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che se 
hai bisogno di PHP non puoi prescindere da librerie javascript, a meno 
di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo 
sul fatto che se vuoi una piattaforma web solida, complessa, sicura e 
robusta non ci sono tante alternative al nostro caro e vecchio php...si 
ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto 
ciò che ha a che fare con node ecc.


Dire che non ci sono alternative è veramente sbagliato. Diciamo che se 
parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io, 
che supportino tutte le tecnologie moderne, dai websocket in su) ci sono 
almeno due alternative: Java (con tutte le sue varianti di librerie e 
framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime.


federico

--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
 Il panda ha l'apparato digerente di un carnivoro (e.g., di un orso).
  Il panda ha scelto di cibarsi esclusivamente di germogli di bambù.
  Quindi, il panda è l'unico animale vegano del pianeta. Il panda
  merita di estinguersi.   -- Maria, Alice, Federico





Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Giuseppe Naponiello
In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che se 
hai bisogno di PHP non puoi prescindere da librerie javascript, a meno 
di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo 
sul fatto che se vuoi una piattaforma web solida, complessa, sicura e 
robusta non ci sono tante alternative al nostro caro e vecchio php...si 
ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto 
ciò che ha a che fare con node ecc.


Il 17/05/23 15:25, Lorenzo Breda ha scritto:
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 
 ha scritto:


On Wed, 17 May 2023, Giuseppe Naponiello wrote:
> (…)mi permette di costruire una piattaforma ben strutturata e
con interfacce
> fighe, magari usando Vue, ma allora devo imparare anche Vue

Le interfacce fighe sono il sistema migliore per creare sistemi
instabili, esigenti di risorse e lente.


Le interfacce fighe sono spesso un requisito, quindi al solito: 
dipende da che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero 
(certo, sono una cosa
in più da gestire, ma se si deve si deve), che richiedano maggiori 
risorse dipende quali
risorse. Di solito i sistemi per "interfacce fighe" riducono di molto 
la necessità di risorse
di rete mentre aumentano la necessità di risorse di calcolo sul 
client. A volte è follia,

a volte è fondamentale. Basta sapere cosa si sta facendo e perché.

In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).


--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Piviul

On 5/17/23 14:06, Diego Zuccato wrote:

[...]
Esattamente quello che dicevo: oltre al linguaggio, che comunque devi 
conoscere, devi studiarti anche il framework.
Tra l'altro prima stavo proprio creando un'app di esempio con Laravel 
e ha iniziato malissimo: due warning per componenti non mantenuti. Col 
primo comando di esempio! :(


questo secondo me è il problema del framework, se  fai software che deve 
durare anni, che devi manutenere, poi aggiornarlo è un bagno di sangue 
fra componenti non più mantenuti, obsoleti... poi c'è sempre il timore 
che il framework muoia... ho visto però che laravel resiste dal 2011, 12 
anni come non sentirli mi sembra, viene voglia in effetti di provarlo.


Piviul




Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Lorenzo Breda
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 
ha scritto:

> On Wed, 17 May 2023, Giuseppe Naponiello wrote:
> > (…)mi permette di costruire una piattaforma ben strutturata e con
> interfacce
> > fighe, magari usando Vue, ma allora devo imparare anche Vue
>
> Le interfacce fighe sono il sistema migliore per creare sistemi
> instabili, esigenti di risorse e lente.
>

Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da
che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero (certo,
sono una cosa
in più da gestire, ma se si deve si deve), che richiedano maggiori risorse
dipende quali
risorse. Di solito i sistemi per "interfacce fighe" riducono di molto la
necessità di risorse
di rete mentre aumentano la necessità di risorse di calcolo sul client. A
volte è follia,
a volte è fondamentale. Basta sapere cosa si sta facendo e perché.

In ogni caso, i framework php hanno zero a che fare con le questioni di
interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve
tutt'altro, come il citato Vue).

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Lorenzo Breda
Il giorno mer 17 mag 2023 alle ore 13:02 Leonardo Boselli 
ha scritto:

>
> Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi
> permettere inefficienze, per cui sempre basso livello. figuriamoci un
> framework,


Se si cerca l'efficienza, php va buttato per intero :P
Un framework ne aggiunge davvero poca di inefficienza (ne toglie se
uno programma da cani, cosa non infrequente nell'ambito).


> che ho ancora da trovarne uno ben documentato.


Laravel. Questo comunque è un problema pure nel mondo dei linguaggi di
programmazione, purtroppo.


> personalmente è meno difficile intendere un programma scritto tutto con le
> funzioni standard che con un framework che uno non conosce.
> E non lo dico solo io ...
>

Su questo dissento decisamente. È meno difficile intendere un programma
scritto
in un linguaggio che conosci che uno scritto in un linguaggio che non
conosci,
ma questo non ha assolutamente nulla a che fare con i framework. Conoscendo
sia vanilla che un framework non c'è gran differenza di leggibilità, e dove
c'è è
decisamente a vantaggio del framework molto spesso (Laravel ad esempio fa
largo uso di un approccio funzionale in cui php è deficitario e che è molto
più
leggibile).

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Diego Zuccato
Finora mi pare siamo stati tutti civili e maturi, sarà l'influenza 
Debian (per la quale sarà meglio che non creino vaccini!) :)


Esattamente quello che dicevo: oltre al linguaggio, che comunque devi 
conoscere, devi studiarti anche il framework.
Tra l'altro prima stavo proprio creando un'app di esempio con Laravel e 
ha iniziato malissimo: due warning per componenti non mantenuti. Col 
primo comando di esempio! :(
Poi l'annoso problema di dover avere una parte al di fuori della webroot 
(già incompatibile con molti servizi di hosting) e oltretutto con 
relative path fissati! Certo, si può spesso giocare sulla config del 
server web (se lo si gestisce in casa), ma non è proprio una cosa simpatica.


Quando poi ci si inizia a mettere di mezzo JS la complessità esplode, 
soprattutto se si vogliono cose astruse come la graceful degradation 
(qualcuno vuole provare a navigare qualche sito con Arachne? O:) ).


Vabbè, mi ritiro nella mia grotta a cercare di lisciare qualche spigolo 
a questa cosa... credo la chiamerò ruota :)


Diego

Il 17/05/2023 13:12, Giuseppe Naponiello ha scritto:

È una di quelle cose che rischia di scatenare flame, spero non avvenga.
Era il mio timore iniziale, ma confido nella maturità e nell'approccio 
"scientifico" alla discussione dei membri del gruppo! 😁


In generale sono d'accordo con te, dipende davvero cosa ci fai. In 
questo momento mi è stato chiesto di sviluppare dei moduli per un CMS 
"semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi 
piace assolutamente ma questo è un altro problema! Il fatto è che la 
tecnologia sta facendo davvero passi da gigante, e spesso questo 
complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un 
ambiente più javascript (e lì ti ci puoi perdere tra le mille 
possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi 
convenga utilizzare Laravel...d'altra parte Laravel mi permette di 
costruire una piattaforma ben strutturata e con interfacce fighe, magari 
usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin!


Il 17/05/23 10:32, Lorenzo Breda ha scritto:
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha 
scritto:



Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale
davvero
la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci 
fai, se tiri su qualche script per hobby probabilmente non ha molto 
senso, se invece fai applicazioni di livello professionale è 
imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit 
testing and esempio sia gratis, eppure è fondamentale e si fa.


Il costo di formazione è l'unico vero svantaggio. La questione della 
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un 
framework rende un'applicazione molto più sicura, altro che meno 
sicura. C'è più gente a trovar falle, ci sono protocolli di testing 
rigidi, la risoluzione delle falle è centralizzata. Certo, le falle 
una volta trovate sono note, ma non credo di dover spiegare qui che la 
security through obscurity sia un'illusione.


Un framework moderno, persino in PHP, non offre particolari problemi 
di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 
8.2 senza particolari sforzi. I framework semplificano anche questo, 
dato che raramente si utilizzano le funzioni "di PHP" più soggette a 
cambiamenti ma si usa la loro versione fornita dal framework, che non 
cambia facilmente API (e quando lo fa è ben documentato nella sezione 
upgrading della documentazione).


Persino sa chi fa solo script, consiglio Laravel Zero.

--
Lorenzo Breda


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione mauro morichi


Il 17/05/2023 13:42, Leonardo Boselli ha scritto:
(…)mi permette di costruire una piattaforma ben strutturata e con 
interfacce

fighe, magari usando Vue, ma allora devo imparare anche Vue


Le interfacce fighe sono il sistema migliore per creare sistemi 
instabili, esigenti di risorse e lente. 



pero' hai sempre l'utonto davanti che si lamenta se l'iconcina non e' 
tre pixel piu' sopra dell'altra, con i colori fighi e le form 
perfette purtroppo.



Mauro


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Leonardo Boselli

On Wed, 17 May 2023, Giuseppe Naponiello wrote:

(…)mi permette di costruire una piattaforma ben strutturata e con interfacce
fighe, magari usando Vue, ma allora devo imparare anche Vue


Le interfacce fighe sono il sistema migliore per creare sistemi 
instabili, esigenti di risorse e lente.


--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it

Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Leonardo Boselli

On Wed, 17 May 2023, Giuseppe Naponiello wrote:
Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la 
pena investire tempo per imparare ad usarne uno

(…)

Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:
Altro problema: se si adotta un framework per un progetto a lunga 
scadenza (10 anni o più), (…)
e chi viene per aiutarti (lo sbarbatello 
che "sa programmare il web") non conosce quel framework perché troppo 
vecchio e fuori moda e quindi comunque deve studiarlo da zero.


Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi 
permettere inefficienze, per cui sempre basso livello. figuriamoci un 
framework, che ho ancora da trovarne uno ben documentato.
personalmente è meno difficile intendere un programma scritto tutto con le 
funzioni standard che con un framework che uno non conosce.

E non lo dico solo io ...

--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225

Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Giuseppe Naponiello

È una di quelle cose che rischia di scatenare flame, spero non avvenga.
Era il mio timore iniziale, ma confido nella maturità e nell'approccio 
"scientifico" alla discussione dei membri del gruppo! 😁


In generale sono d'accordo con te, dipende davvero cosa ci fai. In 
questo momento mi è stato chiesto di sviluppare dei moduli per un CMS 
"semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi 
piace assolutamente ma questo è un altro problema! Il fatto è che la 
tecnologia sta facendo davvero passi da gigante, e spesso questo 
complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un 
ambiente più javascript (e lì ti ci puoi perdere tra le mille 
possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi 
convenga utilizzare Laravel...d'altra parte Laravel mi permette di 
costruire una piattaforma ben strutturata e con interfacce fighe, magari 
usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin!


Il 17/05/23 10:32, Lorenzo Breda ha scritto:
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha 
scritto:



Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale
davvero
la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci 
fai, se tiri su qualche script per hobby probabilmente non ha molto 
senso, se invece fai applicazioni di livello professionale è 
imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit 
testing and esempio sia gratis, eppure è fondamentale e si fa.


Il costo di formazione è l'unico vero svantaggio. La questione della 
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un 
framework rende un'applicazione molto più sicura, altro che meno 
sicura. C'è più gente a trovar falle, ci sono protocolli di testing 
rigidi, la risoluzione delle falle è centralizzata. Certo, le falle 
una volta trovate sono note, ma non credo di dover spiegare qui che la 
security through obscurity sia un'illusione.


Un framework moderno, persino in PHP, non offre particolari problemi 
di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 
8.2 senza particolari sforzi. I framework semplificano anche questo, 
dato che raramente si utilizzano le funzioni "di PHP" più soggette a 
cambiamenti ma si usa la loro versione fornita dal framework, che non 
cambia facilmente API (e quando lo fa è ben documentato nella sezione 
upgrading della documentazione).


Persino sa chi fa solo script, consiglio Laravel Zero.

--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Diego Zuccato
Neanche io vado matto per PHP, ma alla fine fa il suo sporco lavoro. 
Come il C, si può usare in modo pulito o lercio.
Sarà che oramai tendo all'old (non solo school :) ) ma fatico sempre più 
a capire gli assunti alla base di certi framework.


Altre soluzioni (Python e RubyOnRails, per es.) IMO hanno dalla loro una 
maggiore pulizia, ma presentano un grosso scoglio iniziale (studiare il 
linguaggio, studiare le convenzioni, studiare le librerie) e oltretutto 
si "sposano" malissimo a sistemi di shared virtual hosting (nel mio caso 
ISPConfig, ma in ogni caso è molto più difficile trovare un servizio di 
free hosting che li supporti, mentre praticamente tutti offrono PHP).


Diego

Il 17/05/2023 09:22, Federico Di Gregorio ha scritto:

On 17/05/23 09:15, Giuseppe Naponiello wrote:
Non vorrei andare off-topic ma trovo questo discorso molto 
interessante e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di 
sostenitori di Laravel e affini, grazie ai quali hanno notevolmente 
velocizzato il loro lavoro, e un altrettanto grande gruppo di 
sostenitori del metodo "old school", tanto (secondo loro) un framework 
php usa comunque le funzioni di php ma è più complesso ed ha più 
vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale 
davvero la pena investire tempo per imparare ad usarne uno


Più che altro c'è un intero mondo al di fuori del PHP (che io 
personalmente considero uno dei più orrorifici linguaggi di 
programmazione mai inventati).


Il mi consiglio è, anche solo per cultura personale, di provare a dargli 
un'occhiata (poi puoi sempre decidere di rimanere col PHP).


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
   Qu'est ce que la folie? Juste un sentiment de liberté si
    fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Lorenzo Breda
Il mer 17 mag 2023, 09:22 Federico Di Gregorio  ha scritto:

>
> Più che altro c'è un intero mondo al di fuori del PHP (che io
> personalmente considero uno dei più orrorifici linguaggi di
> programmazione mai inventati).
>

C'è sempre JavaScript.

Il mi consiglio è, anche solo per cultura personale, di provare a dargli
> un'occhiata (poi puoi sempre decidere di rimanere col PHP).
>

Da programmatore prevalentemente PHP concordo, ma dico anche che pur con i
suoi problemi residui php8 è un altro linguaggio rispetto a quello che ha
presente il grosso dei critici di PHP.

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Lorenzo Breda
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha
scritto:

>
> Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
> ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero
> la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci fai, se
tiri su qualche script per hobby probabilmente non ha molto senso, se
invece fai applicazioni di livello professionale è imprescindibile. Certo,
impararlo ha un costo, ma non è che fare unit testing and esempio sia
gratis, eppure è fondamentale e si fa.

Il costo di formazione è l'unico vero svantaggio. La questione della
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un framework
rende un'applicazione molto più sicura, altro che meno sicura. C'è più
gente a trovar falle, ci sono protocolli di testing rigidi, la risoluzione
delle falle è centralizzata. Certo, le falle una volta trovate sono note,
ma non credo di dover spiegare qui che la security through obscurity sia
un'illusione.

Un framework moderno, persino in PHP, non offre particolari problemi di
aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 8.2
senza particolari sforzi. I framework semplificano anche questo, dato che
raramente si utilizzano le funzioni "di PHP" più soggette a cambiamenti ma
si usa la loro versione fornita dal framework, che non cambia facilmente
API (e quando lo fa è ben documentato nella sezione upgrading della
documentazione).

Persino sa chi fa solo script, consiglio Laravel Zero.

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Federico Di Gregorio

On 17/05/23 09:15, Giuseppe Naponiello wrote:
Non vorrei andare off-topic ma trovo questo discorso molto interessante 
e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di sostenitori 
di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il 
loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo 
"old school", tanto (secondo loro) un framework php usa comunque le 
funzioni di php ma è più complesso ed ha più vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero 
la pena investire tempo per imparare ad usarne uno


Più che altro c'è un intero mondo al di fuori del PHP (che io 
personalmente considero uno dei più orrorifici linguaggi di 
programmazione mai inventati).


Il mi consiglio è, anche solo per cultura personale, di provare a dargli 
un'occhiata (poi puoi sempre decidere di rimanere col PHP).


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
  Qu'est ce que la folie? Juste un sentiment de liberté si
   fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra



Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Giuseppe Naponiello
Non vorrei andare off-topic ma trovo questo discorso molto interessante 
e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di sostenitori 
di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il 
loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo 
"old school", tanto (secondo loro) un framework php usa comunque le 
funzioni di php ma è più complesso ed ha più vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero 
la pena investire tempo per imparare ad usarne uno


-beppe-

Il 16/05/23 23:33, Paride Desimone ha scritto:

Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:

Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o 
più), poi regolarmente ci si scontra con incompatibilità (era per PHP5.6, con 8.1 quella 
versione non funziona più e devi mettere la nuova, che però ha un'API diversa e finisci 
per dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di dipendenze 
infinite (con relativi problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello 
che "sa programmare il web") non conosce quel framework perché troppo vecchio e 
fuori moda e quindi comunque deve studiarlo da zero.

Per non parlare di un problema di sicurezza: un bug nel framework ti lascia 
esposto a molti più attacchi automatici.


Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una 
nuova ruota.

/paride






Re: apache php e problemi nell' upload dei file

2023-05-17 Per discussione Giuseppe Naponiello

Ok, smanettando mi sono accorto che il problema era davvero "banale".

Il problema del caricamento file non era dovuto (nel mio caso) a 
qualcosa di particolarmente strano, non era legato alla direttiva 
PrivateTmp (ho provato a settarla false ma non è cambiato niente) e non 
era legato all'encoding del form...molto più semplicemente 
move_upload_file non riusciva a spostare il file dalla tmp alla cartella 
definitiva perché, ad un certo punto dello sviluppo e in seguito a 
chissà quale aggiornamento, la cartella di destinazione deve essere 
scritta con percorso assoluto e non più relativo, come avevo sempre 
fatto in passato.


Mi dispiace avervi fatto perdere tempo per una cagata simile ma la 
faccenda dei percorsi non l'ho proprio presa in considerazione visto che 
ha sempre funzionato!


-beppe-


Il 15/05/23 17:12, Federico Di Gregorio ha scritto:

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre 
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file 
da spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come 
risultato sempre /tmp/, se però provo "new 
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive 
correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi 
dirci se sul sistema c'è anche un service che fa partire PHP? Come 
viene gestito?


federico





Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Paride Desimone
Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:
>
>Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 
>anni o più), poi regolarmente ci si scontra con incompatibilità (era per 
>PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che 
>però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti 
>introduce dei bug subdoli), catene di dipendenze infinite (con relativi 
>problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa 
>programmare il web") non conosce quel framework perché troppo vecchio e fuori 
>moda e quindi comunque deve studiarlo da zero.
>
>Per non parlare di un problema di sicurezza: un bug nel framework ti lascia 
>esposto a molti più attacchi automatici.
>

Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una 
nuova ruota.

/paride


-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Sacco
Ciao,

Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto:
[...]
> sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
> sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
> "a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/

Puoi confermare che lo trovi in /tmp/systemd-/tmp e non in
/tmp/systemd- (senza l'ulteriore /tmp finale)?

Ciao,
Giuseppe



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Sacco
Il giorno mar, 16/05/2023 alle 12.54 +0200, Giuseppe Sacco ha scritto:
> Ciao Giuseppe,
[...]
> Per come la vedo io, il sistema dovrebbe funzionare in questo modo:
> apache2
> parte con una /tmp sempre diversa perché nel file
> /lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo
> punto, quando systemd fa partire il processo di apache, gli imposta una
> specie di file system privato (un namespace) nel quale il path /tmp/
> corrisponde ad una directory che dal punto di vista globale è
> /tmp/systemd A quel punto, qualsiasi altro processo avviato da
> apache2
> vedrà la stessa /tmp.
[...]

Puoi anche fare la controprova disabilitando PrivateTmp per apache2 e
verificando che questo sia proprio la causa del problema. Per
disabilitarlo, crea il file
/etc/systemd/system/apache2.service.d/noprivatetmp.conf
con le due righe seguenti:
[Service]
PrivateTmp=false

e poi dai i due comandi, da root, per rileggere i file e riavviare apache2:
systemctl daemon-reload
systemctl restart apache2

Ciao,
Giuseppe



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Diego Zuccato
Beh, anche le mie classi di interfacciamento al db fanno abbastanza 
ridere, di base (p.e. le query mi ritornano comunque un array coi 
risultati, no iteratori, ho preferito la semplicità, non avendo tabelle 
enormi). Però mi è riuscita direi abbastanza bene la gestione delle join :)


Il problema è che gli applicativi o sono fire&forget o tendono a 
crescere stratificandosi, o partono come F&F e dopo qualche anno te li 
fanno estendere (meno male che avevo previsto una discreta modularità in 
partenza :) ). Purtroppo i framework che avevo guardato al tempo mi 
avrebbero richiesto, per iniziare ad usarli decentemente, più tempo di 
quello che avevo a disposizione per realizzare l'applicativo...


Altro problema: se si adotta un framework per un progetto a lunga 
scadenza (10 anni o più), poi regolarmente ci si scontra con 
incompatibilità (era per PHP5.6, con 8.1 quella versione non funziona 
più e devi mettere la nuova, che però ha un'API diversa e finisci per 
dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di 
dipendenze infinite (con relativi problemi di sicurezza), e chi viene 
per aiutarti (lo sbarbatello che "sa programmare il web") non conosce 
quel framework perché troppo vecchio e fuori moda e quindi comunque deve 
studiarlo da zero.


Per non parlare di un problema di sicurezza: un bug nel framework ti 
lascia esposto a molti più attacchi automatici.


Diego

Il 16/05/2023 12:56, Giuseppe Naponiello ha scritto:

oddio che bello, non sono solo!!!

Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) 
che i vari framework sfruttano davvero poco le potenzialità di un db 
come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco 
a fondo le potenzialità di un framework come laravel


Il 16/05/23 11:47, Diego Zuccato ha scritto:
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi 
che alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, 
ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto 
interessante, approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  
ha scritto:


    Il problema è che non trovo una soluzione per caricare un file da
    interfaccia web in una cartella del server: con fetch API e 
formData
    mando il file da caricare al server, che con un funzione php 
dovrebbe

    spostarlo da tmp alla destinazione finale con la classica funzione
    "move_upload_file", l'errore, come previsto, è che php cerca il
    file da
    spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. 
Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che 
PHP veda tmp come cartella temporanea invece di quella reale è un 
effetto ottico di systemd, in realtà legge e scrive correttamente in 
quella giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda




--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Naponiello

oddio che bello, non sono solo!!!

Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) 
che i vari framework sfruttano davvero poco le potenzialità di un db 
come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco 
a fondo le potenzialità di un framework come laravel


Il 16/05/23 11:47, Diego Zuccato ha scritto:
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi 
che alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, 
ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto 
interessante, approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  
ha scritto:


    Il problema è che non trovo una soluzione per caricare un file da
    interfaccia web in una cartella del server: con fetch API e 
formData
    mando il file da caricare al server, che con un funzione php 
dovrebbe

    spostarlo da tmp alla destinazione finale con la classica funzione
    "move_upload_file", l'errore, come previsto, è che php cerca il
    file da
    spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. 
Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che 
PHP veda tmp come cartella temporanea invece di quella reale è un 
effetto ottico di systemd, in realtà legge e scrive correttamente in 
quella giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda






Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Sacco
Ciao Giuseppe,

Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto:
> Buongiorno,
> vecchio problema a cui non ho trovato una soluzioni "pulite".
> 
> Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
> che ne usufruiscono) non scrivono più in /tmp/ ma in 
> /tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
> perché tanto lo sapete meglio di me di sicuro.
[...]

Per come la vedo io, il sistema dovrebbe funzionare in questo modo: apache2
parte con una /tmp sempre diversa perché nel file
/lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo
punto, quando systemd fa partire il processo di apache, gli imposta una
specie di file system privato (un namespace) nel quale il path /tmp/
corrisponde ad una directory che dal punto di vista globale è
/tmp/systemd A quel punto, qualsiasi altro processo avviato da apache2
vedrà la stessa /tmp.

Ora, se l'interprete php è quello della libreria di apache, vienne eseguito
dallo stesso processo (credo) e quindi vede la stessa /tmp; se invece è un
fast cgi, allora comunicano via socket. In questo caso dovresti controllare
quale servizio attiva il fast cgi e, a quel punto, hai la possibilità di
modificare la /tmp del processo fast cgi in modo che sia la stessa di
quello di apache usando il comando JoinsNamespaceOf=apache2.service nel
primo dei due.

Per capire come apache avvia il php devi controllare il sito che hai
configurato.

Ciao,
Giuseppe



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Diego Zuccato
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che 
alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho 
provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto interessante, 
approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha 
scritto:


Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il
file da
spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono 
uno sviluppatore PHP, non userò direttamente la funzione da decenni 
(lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda 
tmp come cartella temporanea invece di quella reale è un effetto 
ottico di systemd, in realtà legge e scrive correttamente in quella 
giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Lorenzo Breda
Il mar 16 mag 2023, 11:41 Giuseppe Naponiello  ha
scritto:

> Ciao Lorenzo,
>
> Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni
> (lavoro con i framework)
>
> Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho
> provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da
> modificare!!!
>

Un altro mondo davvero.

Passando i dati (e il file) via FormData() non mi sembrava fosse necessario
> specificare l'enctype del form, comunque molto interessante, approfondisco!
>

FormData dovrebbe usare l'encoding corretto. Comunque un'occhiata alla
request per vedere se c'è tutto dalla, se c'è dovrebbe correttamente
funzionare passando come primo parametro il nome effettivo del file:
move_uploaded_file($_FILES["nome_campo"]["tmp_name"], $destinazione)

-- 
Lorenzo Breda

>


Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Naponiello

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho 
provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto interessante, 
approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha 
scritto:


Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il
file da
spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono 
uno sviluppatore PHP, non userò direttamente la funzione da decenni 
(lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda 
tmp come cartella temporanea invece di quella reale è un effetto 
ottico di systemd, in realtà legge e scrive correttamente in quella 
giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Naponiello

Ciao, Diego

le 2 direttive che mi indichi sono commentate anche nel mio caso.

Il 16/05/23 10:46, Diego Zuccato ha scritto:
Io uso php-fpm e non ha nessun problema a trovare la cartella dove 
apache mette gli UL...


Nel php.ini sys_temp_dir è commentata.

Magari verifica anche upload_tmp_dir (anche questa da me è commentata).

In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per 
DavLockDB all'interno dei vhost.


Il mio sistema è stato installato seguendo (abbastanza fedelmente) la 
guida "the perfect server" per ISPConfig3.


Diego

Il 16/05/2023 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come 
/tmp potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
  heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
   in quantum physics] A bug that disappears or alters its behavior when
   one attempts to probe or isolate it.







Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Naponiello

Ciao Federico,

Quando Apache viene riavviato la directory usata come /tmp potrebbe 
cambiare e il PHP non la troverebbe più. 

Infatti, questo era il mio grande dubbio!

Il 16/05/23 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
 heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
  in quantum physics] A bug that disappears or alters its behavior when
  one attempts to probe or isolate it.





Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Giuseppe Naponiello

Ciao Piviul,


non sono molto pratico ma non credo tu sia sulla strada giusta

io invece sono sicuro di NON essere sulla strada giusta!!! 😅

cat $(ls /etc/apache2/mods-enabled/php*.load)
# Conflicts: php5
# Depends: mpm_prefork
LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

Il 15/05/23 20:03, Piviul ha scritto:

Il 15/05/23 18:53, Giuseppe Naponiello ha scritto:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?
Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada 
giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ 
dove punta il .load per php? In altre parole posta l'otput di


$ cat $(ls /etc/apache2/mods-enabled/php*.load)

Piviul





Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Diego Zuccato
Io uso php-fpm e non ha nessun problema a trovare la cartella dove 
apache mette gli UL...


Nel php.ini sys_temp_dir è commentata.

Magari verifica anche upload_tmp_dir (anche questa da me è commentata).

In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per 
DavLockDB all'interno dei vhost.


Il mio sistema è stato installato seguendo (abbastanza fedelmente) la 
guida "the perfect server" per ISPConfig3.


Diego

Il 16/05/2023 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
  heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
   in quantum physics] A bug that disappears or alters its behavior when
   one attempts to probe or isolate it.



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Lorenzo Breda
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha
scritto:

> Il problema è che non trovo una soluzione per caricare un file da
> interfaccia web in una cartella del server: con fetch API e formData
> mando il file da caricare al server, che con un funzione php dovrebbe
> spostarlo da tmp alla destinazione finale con la classica funzione
> "move_upload_file", l'errore, come previsto, è che php cerca il file da
> spostare in /tmp/ e non in systemd
>

Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno
sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con
i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella
temporanea invece di quella reale è un effetto ottico di systemd, in realtà
legge e scrive correttamente in quella giusta.

La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova
il file caricato" è dovuto al fatto che il form html non ha correttamente
settato l'enctype a "multipart/form-data", e quindi invece del file viene
caricato il suo nome.

Buona giornata!

-- 
Lorenzo Breda


Re: apache php e problemi nell' upload dei file

2023-05-16 Per discussione Federico Di Gregorio

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del servizio 
di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
 heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
  in quantum physics] A bug that disappears or alters its behavior when
  one attempts to probe or isolate it.



Re: apache php e problemi nell' upload dei file

2023-05-15 Per discussione Piviul

Il 15/05/23 18:53, Giuseppe Naponiello ha scritto:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?
Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada 
giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ dove 
punta il .load per php? In altre parole posta l'otput di


$ cat $(ls /etc/apache2/mods-enabled/php*.load)

Piviul



Re: apache php e problemi nell' upload dei file

2023-05-15 Per discussione Giuseppe Naponiello
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del servizio 
di apache? Giusto?


Il 15/05/23 18:36, mauro morichi ha scritto:

dipende tutto da come viene gestito php.

Se viene caricato come libreria di apache viene eseguito come apache,

se eseguito in fcgi, allora e' un servizio a parte con un suo namespace.

Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto:
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o 
ricaricare php devo agire sul processo che gestisce Apache. 




Re: apache php e problemi nell' upload dei file

2023-05-15 Per discussione mauro morichi

dipende tutto da come viene gestito php.

Se viene caricato come libreria di apache viene eseguito come apache,

se eseguito in fcgi, allora e' un servizio a parte con un suo namespace.

Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto:
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o ricaricare 
php devo agire sul processo che gestisce Apache. 




Re: apache php e problemi nell' upload dei file

2023-05-15 Per discussione Giuseppe Naponiello
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o ricaricare 
php devo agire sul processo che gestisce Apache.


Credo sia l'installazione standard

Spero di averti risposto

-beppe-

Il 15/05/23 17:12, Federico Di Gregorio ha scritto:

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre 
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file 
da spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come 
risultato sempre /tmp/, se però provo "new 
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive 
correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi 
dirci se sul sistema c'è anche un service che fa partire PHP? Come 
viene gestito?


federico





Re: apache php e problemi nell' upload dei file

2023-05-15 Per discussione Federico Di Gregorio

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file da 
spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi dirci 
se sul sistema c'è anche un service che fa partire PHP? Come viene gestito?


federico



apache php e problemi nell' upload dei file

2023-05-15 Per discussione Giuseppe Naponiello

Buongiorno,

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file da 
spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?



Grazie

-beppe-