Validation d'URL ou : Comment j'ai appris à arrêter de m'inquiéter et à aimer l'utilisateur

Il arrive un moment pour chaque développeur Web où il doit effectuer un certain type de validation des entrées. Un formulaire n'est pas un article de blog dans lequel un utilisateur peut parler poétiquement de son amour pour Yahoo Mail dans un champ de courrier électronique. Finalement, il doit y avoir des limites de nombre de mots, des vérifications de caractères spécifiques et des techniques de validation simples qui empêchent l'utilisateur d'envoyer une requête POST indésirable.

Cependant, que se passe-t-il si vous devez valider une URL ? Et pour ajouter une autre couche au problème, que se passe-t-il si vous voulez seulement le nom d'hôte d'une URL, pas de chemins, pas de protocole, juste le "dubya dubya dubya dot" (www.) et le .com.

Commençons par savoir si une URL est une URL. Un lien nécessite un domaine de deuxième et premier niveau, respectivement Walmart et .com dans walmart.com, et un schéma (https://). Sans ces éléments, le lien ne renvoie à rien et ne devient pas différent d'une ligne de texte.

Mais maintenant que nous connaissons les parties d'une URL, nous atteignons une bifurcation ou un chemin de développement. La validation doit-elle restreindre l'utilisateur sur le terrain ou nettoyer la saisie de l'utilisateur lorsque les données sont envoyées au serveur ?

Il y a des avantages et des inconvénients dans les deux options :

---

Validation avant soumission

Si vous empêchez l'utilisateur de soumettre une URL invalide, cela vous permet de récupérer facilement les données côté serveur sans aucun travail supplémentaire en obligeant l'utilisateur à soumettre la structure de saisie exacte dont vous avez besoin. Dans ce cas, l'attribut pattern de l'élément d'entrée combiné à une expression régulière permettrait une bonne validation de champ à l'ancienne.

Voici un exemple de cette approche :

<input type="text" pattern="https?://.*"

Cependant, cela présente l'inconvénient de restreindre l'utilisateur. Cela nécessite que l'utilisateur ait des parties spécifiques dans sa saisie et si vous avez juste besoin qu'il y ait un .com, alors le long modèle d'expression régulière peut être excessif.

---

Validation après soumission

D'un autre côté, si vous choisissez de nettoyer les données après que l'utilisateur les a soumises, cela permet à l'utilisateur de taper n'importe quoi et laisse le serveur décider quoi faire avec les données. Le constructeur d'URL de Javascript effectue la validation pour vous, renvoyant une TypeError si l'entrée n'est pas valide et vous permettant également d'extraire des parties spécifiques de l'URL comme l'origine ou le nom d'hôte.

Voici un exemple de cette approche :

export const formatWebsiteAfterDomain = (website: string): string => {
  if (!website.trim().length) {
    return '';
  }
  const regEx = /:\/\//;
  const websiteTrimmed = website.trim();
  const hasProtocol = regEx.exec(websiteTrimmed);
  const updatedWebsite = hasProtocol
    ? websiteTrimmed
    : `https://${websiteTrimmed}`;

  try {
    const url = new URL(updatedWebsite);
    return hasProtocol ? url.origin : url.origin.replace('https://', '');
  } catch (_err) {
    return websiteTrimmed;
  }
};

Cependant, comme vous donnez à l'utilisateur une grande liberté dans sa saisie, cela nécessite certains compromis dans ce que le serveur fait avec les données. Si l'utilisateur met une URL invalide, qu'en faites-vous ? Utilisez-vous la réponse TypeError et avertissez-vous l'utilisateur ou autorisez-vous simplement le serveur à consommer ce que l'utilisateur a envoyé ? De plus, le constructeur d'URL valide l'entrée en vérifiant s'il existe un schéma présent (https:// ou http://), ce qui peut être trop peu de validation pour vos utilisations.

---

En fin de compte, le chemin emprunté dépend des cas extrêmes spécifiques de votre problème. Une combinaison des deux solutions pourrait être la plus complète et la plus polyvalente, ou l’un des choix pourrait suffire. L'utilisateur peut saisir n'importe quelle entrée et votre solution sera déterminée en fonction de la liberté que vous êtes prêt à accorder à l'utilisateur. Cependant, ce qui reste universel est que la capacité de l'utilisateur à taper n'importe quoi obligera toujours l'utilisateur et le développeur à parvenir à une sorte de compromis (souvent, le développeur obtient un modèle de saisie spécifique et l'utilisateur peut utiliser son application).

Mais comme les particularités de la saisie des utilisateurs sont éternelles, il y aura toujours des développeurs qui proposeront frénétiquement des solutions pour que leurs applications Web ne se cassent pas lorsque les utilisateurs essaient de coller des images dans le champ URL d'un formulaire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!