Html e PHP – SMsoft – informatica e dintorni

npm: eseguire più servizi in parallelo (VITE e PHP)

admin — Tue, 06 May 2025 08:30:00 +0000

Questa la situazione, ma quello che descrivo è applicabile per tanti altri casi simili.

State sviluppando un’applicazione con VUE.JS e l’applicazione ha anche un backend API scritto in PHP.

Avviamo l’applicazione in modalità di debug con:

npm run dev

e solitamente questo attiva un servizio web sulla porta 5173 che possiamo aprire nel browser. Ma per le API PHP che ho in locale? Devo avviare un server web? devo scrivere un altro comando?

La soluzione più semplice è usare il pacchetto npm concurrently da installare con:

npm install --save-dev concurrently

poi modificare il file package.json da qualcosa tipo:

"scripts": {
"dev": "vite",
"build": "run-p type-check \"build-only {@}\" --",

in:

"scripts": {
"dev": "vite",
"dev:php": "php -S127.0.0.1:8765 -t ./",
"dev:all": "concurrently --kill-others \"npm run dev\" \"npm run dev:php\"",
"build": "run-p type-check \"build-only {@}\" --",

ora potremo avviare entrambe i servizi con:

npm run dev:all

ma nessun ci vieta di inserire nel package.json la riga che vedete in dev:all direttamente in dev e quindi lasnciare il classico npm run dev per avviarli entrambe.

Nota:

Ora ci sarà una nuova esigenza da gestire, ovvero come dire all’applicazione di usare due url differenti come base per il puntamento verso il corretto endpoint in modalità sviluppo o produzione.

La soluzione è quella di creare due file di environment, uno chiamato .env.development in cui inseriamo:

NODE_ENV=dev 
VITE_API_BASE_URL=http://127.0.0.1:8765/api/

l’altro chiamato .env.production in cui inseriamo:

NODE_ENV=production 
VITE_API_BASE_URL=/api/

ed infine inseriamo nel file main.ts, prima di fare il createApp() , questo codice:

export const API_BASE_URL = import.meta.env.VITE_API_BASE_URL as string
if (!API_BASE_URL) {
  throw new Error('VITE_API_BASE_URL is not defined')
}

cosa che renderà disponibile nell’app la costante API_BASE_URL da poter utilizzare come prefisso per le nostre chiamate API.

Chiaramente il tutto potete personalizzarlo secondo le vostre esigenze, questo è solo da prendere come spunto.

enjoy!

Apache/PHP e l’header Content-Length sparito

admin — Tue, 25 Mar 2025 09:30:00 +0000

Facendo alcuni test su degli script PHP è risultato che l’header Content-Length, seppur impostato, non veniva restituito da Apache.

Dopo alcune ricerche è emerso che dalla versione 2.4.59, per gli script CGI-like (come PHP) non possono più restituire l’header Content-Length per motivi di sicurezza (rif CVE-2024-24795).

Per ambienti sicuri è possibile ripristinare il precedente funzionamento tramite una nuova direttiva di apache chiamata ap_trust_cgilike_cl.

Per impostarla, creiamo un file chiamato /etc/apache2/conf-available/fix-cgi.conf con all’interno:

SetEnv ap_trust_cgilike_cl 1

e poi abilitiamolo con:

a2enconf fix-cgi
systemctl reload apache2

enjoy!

Laravel ed errore 419 sul login

admin — Tue, 08 Oct 2024 08:30:00 +0000

Se riscontrate l’errore 419 su Laravel, potrebbe dipendere dalla configurazione HttpOnly per i cookie su apache. Ad esempio solitamente utilizzo questa configurazione:

Header always edit Set-Cookie "(?i)^((?:(?!;\s?HttpOnly).)+)$" "$1; HttpOnly"

che comporta l’errore 419 al login su un’applicazione Laravel.

Attenzione

L’attributo HttpOnly serve a impedire l’accesso ai cookie tramite JavaScript, riducendo il rischio di attacchi Cross-Site Scripting (XSS).

Sebbene mitigare gli XSS sia possibile attraverso la sanificazione degli input utente e la rimozione dei tag