Les codes que la page devait connaître : ce qu'un contrôle navigateur doit savoir
Le défi
Le paiement de Brightloom vérifie votre code de réduction dans le navigateur avant de déranger le serveur, pour qu'un client qui se trompe de saisie soit prévenu tout de suite. Pour cela, il doit connaître tous les codes, et pour les connaître, il faut qu'on les lui envoie tous. La bannière en annonce un. La page en transporte cinq, avec leurs dates et leurs pourcentages, et l'un d'eux est valide aujourd'hui et n'aurait jamais dû sortir de l'entrepôt. Nommez-le.
Ce que tu vas apprendre
- Comprendre que la validation côté client nécessite d'envoyer les données servant de référence
- Lire une liste d'enregistrements compacte dans un champ de formulaire caché
- Éliminer des candidats à l'aide des dates fournies par la page elle-même
- Identifier quelle entrée n'a pas de contrôle d'éligibilité côté serveur, et pourquoi
- Expliquer pourquoi un champ caché est une publication, pas un secret
Compétences testées
Prérequis
- Ce que sont un formulaire HTML et un champ caché
Comment ça marche
Valider la saisie dans le navigateur est utile pour les utilisateurs. Un client qui se trompe en tapant un code doit être prévenu instantanément plutôt que d'attendre un aller-retour vers le serveur. Le problème est structurel, pas accidentel : pour vérifier une réponse, le vérificateur a besoin de la réponse, donc une page capable de dire qu'un code est invalide a reçu tous les codes valides.
C'est vrai pour tout contrôle côté client de cette forme. Types de fichiers autorisés, domaines d'e-mail bloqués, valeurs de commande minimales par région, quelles fonctionnalités appartiennent à quel plan : si c'est la page qui décide, c'est la page qui sait. Cacher le champ ne change rien. Un champ caché n'est ni chiffré, ni en lecture seule, ni privé, il est simplement non affiché, et Voir la source le montre intégralement.
La seconde partie est celle qui coûte de l'argent. Le commentaire explique que les codes clients sont revérifiés par rapport à la commande côté serveur, tandis que les codes du personnel sont acceptés sur le seul code parce que les terminaux portables en magasin n'ont pas de client à vérifier. Cette exception est défendable dans l'entrepôt et indéfendable sur un paiement public, et c'est l'envoi de la liste au client web qui a relié les deux.
Erreurs fréquentes
- Répondre AUTUMN15. Il est actif, et il est annoncé dans la bannière en haut de la page. Rien n'a été divulgué.
- Répondre YULE30. Quarante n'est pas le plus grand nombre ici, trente est le suivant, mais sa fenêtre commence le 1er décembre.
- Répondre SPRING10. Expiré le 30 juin.
- Répondre WELCOME5. Dans la fenêtre, mais la page enregistre
customer_typecomme returning, et l'API vérifie les codes clients par rapport à la commande. - Utiliser sa propre horloge. La page transporte la date du serveur dans un champ caché. Utilisez-la.
Comment s'en protéger
Vérifiez côté serveur, et ne donnez au client que ce dont il a besoin pour poser la question.
- Validez le code par une requête. Si un retour instantané est important, envoyez le code saisi à un point d'entrée qui répond valide ou non pour cette commande, et ne renvoyez rien d'autre.
- Si un préfiltre est réellement souhaité, ne transportez que les codes déjà publics. Les codes internes et ceux du personnel ne devraient jamais atteindre un client web, ce que précise exactement le ticket mentionné dans le commentaire.
- Supprimez l'exception plutôt que la divulgation. Un code du personnel accepté sur le seul code est un bearer credential. Liez-le à une session de personnel authentifiée ou à un terminal enregistré.
- Limitez le débit des tentatives d'utilisation et déclenchez une alerte lorsqu'un code est utilisé hors du canal auquel il appartient. Un code d'entrepôt utilisé sur le paiement public est une alerte d'une ligne.