Formulari estàtic: comprovar backend i lliurament de correu

Un botó que mostra «gràcies» no demostra que ningú hagi rebut cap missatge. Una web creada amb IA pot tenir formulari i validació visual sense backend per processar peticions. Abans de triar allotjament, identifica quina etapa funciona i quina falta.

Aquesta guia utilitza Buzón de ensayo, exemple original MIT amb Node. El repositori públic conté el codi per reproduir les proves locals, no una demo backend pública. El mode normal valida dades sintètiques, sense enviar correu ni guardar contactes.

Quatre etapes, quatre evidències

MDN explica la validació i per què cal repetir els controls al servidor. Un client pot saltar-se la interfície. A DevTools revisa URL, mètode, estat i resposta: un 200 només significa el que defineix aquell endpoint.

Assaig local sense proveïdor

Amb una còpia de l’exemple, instal·la Node 22.23.3 des de Node.js i comprova v22.23.3. Conserva lockfile i llicència. No hi ha dependències externes ni credencials.

git clone https://github.com/ocentelles/hostbrid-example-form.git
cd hostbrid-example-form
git checkout e949f6a14258eced69d1a3e47dbb6909b35639cc
node --version
npm ci --ignore-scripts --offline
npm run check
npm test
PORT=8080 npm start

Obre http://127.0.0.1:8080/ amb dades fictícies com demo@example.invalid. Mantén el procés actiu. Només escolta en loopback: no és una demo pública HTTPS. Fes servir aquest origen exacte; localhost no és equivalent. FORM_ORIGIN configura l’origen admès, no DNS, certificats ni accés públic.

Des d’un altre terminal, apunta només a aquesta demo local:

curl -fsS http://127.0.0.1:8080/healthz
curl -s -i http://127.0.0.1:8080/api/contact \
  -H 'Origin: http://127.0.0.1:8080' \
  -H 'Content-Type: application/json' \
  --data '{"name":"Persona Demo","email":"demo@example.invalid","message":"Mensaje sintético de ensayo.","website":""}'

Espera 200, accepted:true i delivery:"not-sent". El rebut confirma validació local, no transport de correu. /healthz indica lliurament desactivat i comptador efímer; no comprova cap proveïdor ni bústia.

Prova el rebuig, no només la portada

curl -s -i http://127.0.0.1:8080/api/contact \
  -H 'Origin: https://other.example.invalid' \
  -H 'Content-Type: application/json' \
  --data '{"name":"Persona Demo","email":"demo@example.invalid","message":"Mensaje sintético de ensayo.","website":""}'

Ha de retornar 403. També es proven origen absent/null, tipus incorrecte 415, JSON/UTF8 invàlids 400, cos superior a 4096 bytes 413, lectura incompleta 408 i camps invàlids 422. Rutes no declarades 404 i mètodes no admesos 405. Després de cinc intents POST per minut i adreça de socket, els següents retornen 429; els intents invàlids també compten.

Aquestes proves són locals i sintètiques. No executis la càrrega contra formularis aliens ni confonguis el límit bàsic amb una garantia DDoS. L’exemple ignora X-Forwarded-For: darrere d’un proxy, diversos visitants poden compartir adreça. Un servei públic requereix proxy de confiança i límits compartits.

Què acrediten els controls

Origin i Fetch Metadata redueixen peticions d’altres orígens del navegador, però no autentiquen bots que falsifiquen capçaleres. El honeypot demana un camp buit: és una heurística, no un CAPTCHA. La sintaxi email no prova propietat ni lliurament. El limitador funciona per procés i es reinicia amb ell.

La segona fase injecta simulacions locals (mocks) de verificador i lliurament només en mode de prova explícit. Comprova rebuig, errors i temps d’espera esgotats, sense verificar cap persona ni connectar proveïdors. La clau d’idempotència lliga contingut i intent: reintents concurrents comparteixen execució; contingut diferent o token reutilitzat amb una altra clau retorna 409. Memòries cau de claus i hashes i el control de reutilització de tokens duren cinc minuts en memòria, sense garanties distribuïdes o duradores. Un temps d’espera esgotat no prova que un proveïdor extern hagi cancel·lat un efecte.

Turnstile requereix Siteverify al servidor; mostrar un widget no completa la integració. Aquest exemple no té widget ni verificació real de tokens. Una integració futura requeriria secret només servidor, valors hostname i action esperats i controls de fallades i reutilització de tokens.

Abans d’afirmar lliurament real

L’exemple va superar 43 proves locals, amb comprovacions en Chrome a 390 i 1280 px. Demostren el contracte local i les simulacions, no SMTP, Nodemailer, OAuth, desplegament automàtic després d’un push, domini públic o recepció de correu. No s’ha triat cap proveïdor ni contractat cap compte per a l’exemple.

Un proveïdor d’enviament requereix configuració pròpia: remitent/destinatari controlats per l’operador, clau només servidor, domini verificat quan pertoqui, errors i reintents i destinació de prova autoritzada. El client no ha de triar destinataris o remitents arbitraris. Resend documenta estats d’enviament: referència de proveïdor, no integració provada aquí. Revisa esdeveniments, rebots i destinació: acceptació no equival a arribada a la safata.

Triar on viu el backend

Per a un procés Node permanent, valora Projects amb pla que inclogui serveis i quota lliure. Un VPS pot encaixar si necessites controlar l’entorn i assumir sistema, xarxa i operació. L’exemple escolta només en loopback: adaptació a l’allotjament i HTTPS necessiten proves separades. Quota estàtica no implica serveis gratuïts.

Si encara identifiques l’arquitectura, consulta allotjar una web creada amb IA i diagnosticar un procés Node. Correu de domini cobreix bústies: contractar-ne una no demostra un backend transaccional per al formulari. Decideix enviament i allotjament per separat, revisant condicions i preus actuals.