Formulaire statique : vérifier le backend et la livraison

Un bouton affichant « merci » ne prouve pas la réception d’un message. Un site créé avec l’IA peut proposer un beau formulaire et une validation visuelle sans backend pour traiter les requêtes. Avant de choisir un hébergement, identifiez l’étape fonctionnelle et celle qui manque.

Cette méthode utilise Buzón de ensayo, exemple original Node sous MIT. Le dépôt public fournit le code pour reproduire les tests locaux, pas une démo backend publique. Le mode normal valide des données synthétiques sans envoyer de courrier ni stocker de contacts.

Quatre étapes, quatre preuves

MDN explique la validation et la nécessité de refaire les contrôles côté serveur. Un client peut contourner l’interface. Dans DevTools, inspectez URL, méthode, statut et réponse : 200 signifie seulement ce que définit cet point de terminaison.

Essai local sans fournisseur

Avec une copie de l’exemple, installez Node 22.23.3 depuis Node.js et vérifiez v22.23.3. Conservez lockfile et licence. Aucune dépendance externe ni identifiant secret.

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

Ouvrez http://127.0.0.1:8080/ avec des données fictives comme demo@example.invalid. Maintenez le processus actif. Il écoute uniquement sur loopback : ce n’est pas une démo HTTPS publique. Utilisez cette origine exacte ; localhost n’est pas équivalent. FORM_ORIGIN configure l’origine autorisée, pas DNS, certificats ou accès public.

Depuis un autre terminal, ciblez uniquement la démo locale :

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":""}'

Attendez 200, accepted:true et delivery:"not-sent". Le reçu confirme une validation locale, pas un transport de courrier. /healthz indique livraison désactivée et compteur éphémère ; il ne vérifie ni fournisseur ni boîte mail.

Tester le rejet, pas seulement l’accueil

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":""}'

Le résultat attendu est 403. Les tests couvrent aussi origine absente/null, type incorrect 415, JSON/UTF8 invalide 400, corps dépassant 4096 octets 413, lecture incomplète 408 et champs invalides 422. Routes non déclarées 404, méthodes interdites 405. Après cinq tentatives POST par minute et adresse de la connexion, les suivantes donnent 429 ; les tentatives invalides comptent aussi.

Ces essais sont locaux et synthétiques. Ne lancez pas cette charge sur un formulaire tiers ; un limiteur simple n’est pas une garantie DDoS. L’exemple ignore X-Forwarded-For : derrière un proxy, plusieurs visiteurs peuvent partager une adresse. Un service public demande configuration du proxy de confiance et limites partagées.

Limites des contrôles

Les en-têtes Origin et Fetch Metadata réduisent les requêtes de navigateurs depuis d’autres origines, sans authentifier les bots falsifiant les en-têtes. Le honeypot impose un champ vide : heuristique, pas CAPTCHA. Une syntaxe email correcte ne prouve ni propriétaire ni livraison. Le limiteur fonctionne par processus et disparaît au redémarrage.

La deuxième phase injecte des simulations locales (mocks) de vérification et livraison uniquement en mode test explicite. Rejet, erreurs et dépassements de délai sont testés sans vérifier une personne ni connecter un fournisseur. La clé d’idempotence lie contenu et tentative : les nouvelles tentatives simultanées partagent l’exécution ; contenu différent ou jeton réutilisé avec une autre clé donne 409. Caches de clés et de hashes et la protection contre la réutilisation de jetons durent cinq minutes en mémoire, sans garantie distribuée ou durable. Un dépassement de délai ne prouve pas qu’un fournisseur externe a annulé un effet.

Turnstile exige Siteverify côté serveur ; afficher un widget ne suffit pas. Cet exemple ne contient ni widget ni vérification réelle de jeton. La future intégration nécessiterait secret serveur, valeurs hostname et action attendues et vérification des échecs et réutilisations de jetons.

Avant d’affirmer une livraison réelle

L’exemple a réussi 43 tests locaux, avec des rendus dans Chrome à 390 et 1280 px. Ils prouvent le contrat local et les simulations, pas SMTP, Nodemailer, OAuth, déploiement automatique après un push, domaine public ou réception de courrier. Aucun fournisseur choisi ni compte acheté pour cet exemple.

Un fournisseur d’envoi exige sa configuration : expéditeur/destinataire contrôlés par l’opérateur, clé serveur, domaine vérifié si nécessaire, erreurs et nouvelles tentatives et destination de test autorisée. Le client ne doit pas choisir des destinataires ou expéditeurs arbitraires. Resend documente les états d’envoi : référence de fournisseur, pas intégration testée ici. Vérifiez événements, rebonds et destination ; acceptation n’est pas arrivée en boîte de réception.

Choisir où exécuter le backend

Pour un processus Node permanent, envisagez Projects avec un plan incluant des services et un quota disponible. Un VPS convient éventuellement si vous voulez contrôler l’environnement et assumez système, réseau et exploitation. L’exemple écoute seulement sur loopback : adaptation à l’hébergement et HTTPS restent à tester. Quota statique ne signifie pas services gratuits.

Pour identifier l’architecture, consultez héberger un site créé avec l’IA et diagnostiquer un processus Node. Le courrier de domaine concerne les boîtes mail : en acheter une ne prouve pas un backend transactionnel pour formulaire. Choisissez envoi et hébergement séparément, selon conditions et prix actuels.