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ù?
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
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.
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.
ok, quindi in php.ini devo decommentare la sezione che gestisce laCiao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada
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?
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 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....
non sono molto pratico ma non credo tu sia sulla strada giustaio invece sono sicuro di NON essere sulla strada giusta!!! 😅
Il 15/05/23 18:53, Giuseppe Naponiello ha scritto:
ok, quindi in php.ini devo decommentare la sezione che gestisce laCiao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/
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?
dove punta il .load per php? In altre parole posta l'otput di
$ cat $(ls /etc/apache2/mods-enabled/php*.load)
Piviul
Quando Apache viene riavviato la directory usata come /tmp potrebbeInfatti, questo era il mio grande dubbio!
cambiare e il PHP non la troverebbe più.
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.digregorio@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.
Sono uno sviluppatore PHP, non userò direttamente la funzione daPrima 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!!!
decenni (lavoro con i framework)
La mia esperienza è che il 99.99% degli errori "PHP/java/swift non miPassando i dati (e il file) via FormData() non mi sembrava fosse
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.
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello <beppenapo@gmail.com> 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,<html>
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
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.
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!!!
specificare l'enctype del form, comunque molto interessante, approfondisco!
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 daPrima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia,
decenni (lavoro con i framework)
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 nonPassando i dati (e il file) via FormData() non mi sembrava fosse
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.
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 <beppenapo@gmail.com>
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
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.
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/
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'APIdiversa 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
Per non parlare di un problema di sicurezza: un bug nel framework ti lascia esposto a molti più attacchi automatici.
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
Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato <diego.zuccato@unibo.it> ha scritto: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
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
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
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
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
(…)mi permette di costruire una piattaforma ben strutturata e con interfacce
fighe, magari usando Vue, ma allora devo imparare anche Vue
(…)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.
È 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! 😁
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello <beppenapo@gmail.com> 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.<html>
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
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 <diego.zuccato@unibo.it> 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 ...
[...]
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! :(
In ogni caso, i framework php hanno zero a che fare con le questioniOvviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve tutt'altro, come il citato Vue).
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli
<leo5css@trail.it> 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:<html>
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
In ogni caso, i framework php hanno zero a che fare con le questioniOvviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve
tutt'altro, come il citato Vue).
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.
On 17/05/23 16:54, Giuseppe Naponiello wrote:
In ogni caso, i framework php hanno zero a che fare con le questioniOvviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve
tutt'altro, come il citato Vue).
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
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli <leo5css@trail.it>
On Wed, 17 May 2023, Giuseppe Naponiello wrote:
(…)mi permette di costruire una piattaforma ben strutturata e conLe interfacce fighe sono il sistema migliore per creare sistemi
interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue
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é.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 05:08:55 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,335,948 |