Condividi localhost: test su smartphone e webhook

Prima di condividere: controlla l’indirizzo locale

Guarda l’URL mostrato dal server di sviluppo. Protocollo e porta contano: http://localhost:5173 e https://localhost:7143 sono destinazioni diverse. Apri esattamente quell’indirizzo ed esegui un’azione tipica prima di creare il tunnel.

Un test utile sul telefono in cinque minuti

Navigazione e impaginazione

Apri il menu, ruota il telefono e visita una pagina lunga. Cerca scorrimento orizzontale, pulsanti coperti e contenuti nascosti da un’intestazione fissa. L’emulazione del browser aiuta, ma non riproduce ogni interazione reale.

Moduli e sessione

Tocca ogni campo e invia un valore non valido, poi uno valido. Verifica che gli errori restino visibili sopra la tastiera. Se l’accesso funziona solo sul computer, prova una nuova sessione e controlla callback e cookie.

Richieste e caricamento

Prova una pagina ricca di immagini e un’azione che carica dati. Una risposta lenta sulla connessione domestica non misura le prestazioni in produzione. Annota pagina, dispositivo e azione per riprodurre il problema in locale.

Mostra il lavoro a un cliente

Invia la pagina precisa da esaminare. Spiega cosa provare e quando chiuderai l’anteprima.

Ecco l’anteprima per la revisione di oggi. Controlla il menu mobile e il modulo di contatto. Il link verrà chiuso dopo la chiamata.

Ricevi un webhook in locale

Un servizio webhook non raggiunge localhost sul tuo computer. Fornisci l’indirizzo pubblico del tunnel con il percorso di callback. L’esempio presume che l’app gestisca già richieste POST su /api/webhooks/demo.

1. Sostituisci YOUR-TUNNEL con il nome host effettivo e inserisci l’URL di callback completo nelle impostazioni di test del fornitore.
2. Mantieni attiva la verifica delle firme. Conserva localmente il segreto del webhook e invia un evento di prova dal fornitore.
3. Controlla stato di consegna e log locali. Restituisci la risposta di successo prevista e gestisci i nuovi tentativi senza ripetere l’azione.

Una richiesta di password nel browser può bloccare il mittente del webhook. Usa un endpoint raggiungibile dal fornitore e verifica le richieste firmate. CORS riguarda le richieste del browser, non i webhook tra server.

Esempio: verificare le firme dei webhook GitHub ↗

Controlla la risposta del webhook, non solo il browser

Aprire il callback nel browser invia di solito GET. Molti endpoint webhook attendono POST: un errore del browser non dimostra un problema di consegna. Invia l’evento di prova del fornitore e confronta orario e ID di consegna con il log locale.

404 / 405

Verifica percorso e metodo HTTP. Usa la porta dell’API, non necessariamente quella del frontend. Una home page raggiungibile non dimostra che esista l’endpoint di callback.

401 / 403

Individua il rifiuto: password dell’anteprima, autenticazione dell’app o verifica della firma. Per i dati firmati rispetta le regole sul corpo originale della richiesta; analizzarlo e riscriverlo prima della verifica può invalidare la firma.

5xx / Timeout

Controlla che l’app sia attiva e abbia ricevuto la richiesta. Per elaborazioni lente rispetta la scadenza del fornitore e usa attività in background quando opportuno. Prova una consegna ripetuta per evitare ordini o messaggi duplicati.

Usa la modalità di test del fornitore e non registrare segreti o dati personali completi. Un test riuscito verifica consegna ed elaborazione dell’app, ma non sostituisce i requisiti d’integrazione del fornitore.

Il link si apre, ma qualcosa non funziona?

Concludi il test e interrompi la condivisione

Interrompi la condivisione in GhostlyShare o il tunnel nel terminale con Ctrl+C. La scadenza può chiudere automaticamente un’anteprima programmata. Al termine rimuovi anche gli URL di callback temporanei dal fornitore.

Domande sulle anteprime locali