2017-06-13 7 views
-1

Mon formulaire de contact a reçu une tonne de messages de spam. Mon formulaire de contact a plusieurs champs. J'ai remarqué que le champ d'adresse de courrier électronique des messages de spam contient toujours le fort Staceyrow et le champ de message contient toujours un ou plusieurs de ce qui suit: salaire, prêt, prêts, prêteur, prêteurs. Le champ de localisation contient toujours le mot Darussalam. J'utilise un formulaire de contact php et sur le backend, je suis capable d'entrer une regex pour chaque champ. Quelle regex dois-je entrer pour le champ email de sorte que si l'utilisateur entre quelque chose contenant "Staceyrow" (non sensible à la casse) dans ce champ, le formulaire ne soumet pas? Quelle regex dois-je entrer pour le champ de message de sorte que si l'utilisateur entre quelque chose contenant "payday" ou "prêt" ou "prêts" ou "prêteur" ou "prêteurs", (non sensible à la casse) dans ce champ, le formulaire ne pas soumettre?Interdire certaines chaînes de caractères

Quelle regex dois-je entrer pour le champ de localisation, donc si l'utilisateur entre quelque chose contenant "Darussalam" (non sensible à la casse) le formulaire ne pas soumettre?

+1

Qu'avez-vous déjà essayé? –

+0

pourquoi ne pas ajouter un CAPTCHA? – rtfm

+0

Vous pourriez être intéressé par cette question: [Comment empêcher les robots de remplir automatiquement un formulaire?] (Https://stackoverflow.com/questions/2387496/how-to-prevent-robots-from-automatically-filling-up -une forme) –

Répondre

2

Match "Staceyrow" avec /staceyrow/i

Match "salaire", "prêt", "prêts", "prêteur", ou "prêteurs" avec /(?:loans?|payday|lenders?)/i (* juste faire attention sur la correspondance des valeurs de champ de message innocents)

match « Darussalam » avec /darussalam/i

Si vous utilisez ces critères pour refuser le dépôt de forme et/ou fournir des commentaires spécifiques sur le refus, les concepteurs de bots seront en mesure d'ajuster facilement leurs valeurs de spamming sans se soumettre. Peut-être faire une sorte de règle où le formulaire semble toujours soumettre, mais il y a soit un message d'erreur généralisé "quelque chose s'est mal passé", ou pas de message d'erreur et la soumission est jetée dans une table de base de données inactive , où vous pouvez le scanner manuellement pour vous assurer qu'aucun utilisateur innocent n'a été détecté sur votre écran.

Ou peut-être que vous pourriez autoriser les utilisateurs suspects à soumettre, mais juste avoir une colonne supplémentaire dans votre table de base de données qui marque l'utilisateur comme "suspect". Les utilisateurs suspects peuvent avoir des privilèges très limités jusqu'à ce que les yeux humains prennent une décision.

Comme l'indique un astérisque précédemment, "slender" lèvera un drapeau dans le champ de message parce que. Pour cette raison, le champ de message est le moins fiable pour identifier les pommes défectueuses. Oh, et si vous envisagez d'élargir votre modèle de message, placez les chaînes les plus courtes dans les alternatives précédentes et les chaînes plus longues vers l'arrière pour des raisons de performances.