stop af bots med Javascript

hurtig oversigt

er en praktisk gå til teknik til at stoppe spam, men det er også utilgængeligt. Brug af Javascript til at fjerne kritiske formularattributter, indlæsning af formularindhold dynamisk og udskiftning af indsendelsesknapper kan være et effektivt alternativ, der opretholder dine sider tilgængelighed.

tidligere havde jeg brugt.net MVC som ramme for hjemmesiden. Kontaktformularen skulle være tilgængelig og kunne ikke stole på noget plugin, der ville påvirke en brugers evne til at kontakte os negativt. Formularen havde et CSS skjult formularfelt ved hjælp af honeypot-teknikken og serversidelogikken, der afviste alle indsendelser, hvis formularfeltet indeholdt data.

teorien om at være bots kan ikke forstå, hvad der er et legitimt felt, og hvad der ikke er, så botten identificerer og udfylder alle inputfelter og sender formularen. Hvis feltet indeholder data, antager vi, at da en bruger ikke har været i stand til at navigere til det skjulte formularfelt, har en bruger ikke indsendt formularen og kasseret hele input.

Honeypot-teknikker identificeres altid som en effektiv måde at stoppe spam-e-mails på, og for mig fungerede teknikken ok for at reducere spam til et håndterbart niveau om dagen. Inden for min mail-klient ville jeg vælge alle spam-e-mails og slette dem på masse, alle temmelig ligetil, hvis tidskrævende.

flytning til Netlify #

som en del af skiftende infrastruktur blev hjemmesiden flyttet til Netlify, hvilket betød, at den eksisterende spamfiltreringsteknik, der blev påberåbt, skulle genovervejes, da det forrige sted blev bygget i.net og hostet i et. net-miljø.

oprindeligt valgte jeg at gå uden spambeskyttelse og bare se, hvordan det gik. Som du ville forvente, kom spam-indlægene tykke og hurtige.

brug af en honeypot #

Netlify giver en honeypot-funktion, der følger den samme teknik til at bruge et skjult inputfelt, og hvis dette er udfyldt, sendes alle e-mails til spam-mappen.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">
<input class="actual-hidden" name="bot-field" tabindex="-1">

teknikken fungerede meget effektivt; ingen legitime e-mails nåede nogensinde den almindelige e-mail-mappe.

men spam-mappen fortalte en anden historie. Der var sider med spam-resultater, hvor jeg tidligere kunne vælge alle e-mails på masse og slette, netlify-tilgangen betød, at kun 10-20 e-mails blev returneret ad gangen med personsøgning, der blev brugt til at flytte til de næste ti e-mails. Der var ingen masse Slet funktion, og jeg var nødt til at slette individuelle.

dette var utroligt tidskrævende og kedeligt. Jeg skrev en Javascript bookmarklet, som jeg håbede ville gøre det lettere at markere alle afkrydsningsfeltkontroller på siden og slette alle poster.

desværre genkendte sidelogikken ikke min Bogmærke som fysisk interageret med hver kontrol og ville ikke tillade valg af alle e-mails på masse.

jeg kunne heller ikke være sikker på, om nogen e – mails i spam-mappen var falske positive-forkert identificerede e-mails, hvilket betød, at jeg måtte gennemgå alle e-mails for at bekræfte.

diskontering af re #

Netlify giver Google re, og jeg overvejede oprindeligt brugen, da e-mails steg dagligt.

men opfattelsen af et internettilgængelighedsfirma, der bruger en kendt utilgængelig metode for folk til at kontakte dem, var ikke et godt udseende.

jeg har tidligere skrevet om, hvor forfærdelig en teknik er for at underminere tilgængeligheden af en hjemmeside og tænkte, hvis jeg ikke kunne løse dette problem, hvad håb er der for andre.

jeg besluttede at programmere min vej ud af det.

gør formularen mindre attraktiv for bots #

jeg havde brug for at få kontaktformularen til at se mindre ud som en kontaktformular og mindre attraktiv for bots. Jeg begyndte at fjerne method attributten på formelementet. Hvis der ikke er nogen method attribut, regnede jeg med, at formularen ikke kunne sendes.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">

desværre, selvom attributten blev fjernet, anvendte Netlify metodeattributten tilbage på formularen, da stedet blev implementeret, og det var noget, jeg ikke kunne kontrollere.

<form name="contactSubmission" method="post">

brug af Jfor til at fjerne en attribut #

jeg besluttede at bruge Javascript til dynamisk at fjerne attributten method, efter at siden var indlæst. Ved hjælp af begivenheden klar til søgning vælges formularelementet, og attributten method fjernes.

$(function(){
$("#contactSubmission").removeAttr("method");
});

jeg krævede derefter en måde at tilføje attributten tilbage på formularelementet før afsendelse. Jeg var nødt til at tilføje det tilbage i en rækkefølge for at sikre, at attributten eksisterer, før formularen sendes, ellers vil formularen fejle ud, og brugeren vil støde på en brudt kontaktformular, næppe ideel!

udskiftning af sendeknappen #

derudover havde jeg besluttet at fjerne submit knappen også. Finde ud af, om der ikke var nogen submit – knap, kan formularen ikke indsendes via en hovedløs bro.ser (hvis spammere brugte denne teknik), da det ligner mindre en kontaktformular og mere som en samling inputfelter.

Formularindsendelse ville kun finde sted via et regelmæssigt button element programmatisk.

<input type="button" value="Contact CANAXESS" 
class="contactForm-button submit">

tilføjelse af metodeattributten ved indsendelse #

den almindelige knap havde en click hændelseshandler, der tilføjede metodeattributten og værdien tilbage på formularelementet.

når der klikkes på knappen, tilføjes attributten, men der kan være tilfælde, hvor timingen af scriptelementer sker i modsætning til, hvordan jeg ville have det.

for at overvinde dette tilføjede jeg et timerinterval. Dette kontrollerer gentagne gange formularelementet for attributten method hver 100 millisekunder, hvis der ikke findes nogen attribut method, sendes formularen ikke.

$("input.contactForm-button").click(function(){
$("#contactSubmission").attr("method", "post");
var checkExist = setInterval(function(){ 
var attr = $("#contactSubmission").attr("method");
if (typeof attr !== typeof undefined && attr !== false)
{
$("#contactSubmission").submit();
clearInterval(checkExist);
}
}, 100);
});

Formularindsendelse sker kun, når attributten method eksisterer, og dette vil ske programmatisk. Når formularen var blevet indsendt intervallet timeren ville ende.

clearInterval(checkExist);

jeg troede, det var en temmelig effektiv måde at over engineering en kontaktformular til at stoppe bots, men min tillid var ikke til at vare. Jeg kom tilbage et par timer senere for at finde spam-e-mails, der indsamles igen.

Formularindsendelse sker via HTTP #

og så gik det op for mig, bots besøger sandsynligvis ikke engang siden via bro.sereren, de er ligeglad med alt det jesperyskript, der kører på klientsiden og fjerner elementer.

metodeattributten findes, når siden indlæses, og derfra er det en simpel skrabe af HTML og indsendelse af formularen via et HTTP-indlæg uden nogensinde at interagere med siden.

og det var denne erkendelse, som derefter fik mig til at identificere den teknik, der ikke bare ville bremse spam-e-mails, men stoppe dem. Siden jeg anvendte denne teknik, har jeg ikke haft nogen e-mails, ingen, sil.

adskillelse af siden fra formularen #

teknikken indlæser formularfragmentet via Javascript, efter at siden er indlæst. At indse spam-bots bruger sandsynligvis ikke en hovedløs bro.ser til at navigere på kontaktsiden og indsende den formular, jeg i stedet lavede formularen, vises kun, når siden er indlæst fra en bro. ser.

kontaktsiden gengivet i bro.ser er en side, men er i virkeligheden består af to dele. Hovedsiden med en pladsholder for formularkomponenten og selve formularindholdet.

<div></div>

indlæsning af formularen på sideindlæsning #

når siden indlæses, indlæser en jfor-klar begivenhed det ekstra formularfragment i formularbeholderen DIV næsten øjeblikkeligt.

formularfragmentsiden identificeres aldrig af en bot, da den oprindelige side, som boten ser, ikke har noget formelement, dette indlæses først, når siden er indlæst via Javascript.

<script>
$(function(){
$("#formContainer").load("formfragment.html");
});
</script>

sammenfattende #

teknikken kræver Javascript for at fungere. Da Javascript er blevet en accepteret del af internetudviklingen, synes jeg, det er en realistisk løsning til at stoppe spam i bestemte specifikke situationer.

den anden teknik til at bruge honeypot-felter er altid problematisk, da det fra min erfaring ikke var så effektivt.

Spam ville stadig finde en vej igennem, og hvis jeg er ærlig, kan honeypot-teknikken kun klassificeres som en spambegrænser, hvilket reducerer forekomsten af spam, der kommer igennem.

mens brugen ville fungere og være en hurtig løsning, undergraver brugen af at gøre internettet tilgængeligt for handicappede.

ved at fjerne kontaktformularen fra at blive gengivet som en del af en almindelig HTTP get-anmodning, ser dens synlighed til bots ud til at være markant reduceret og reducerer (og i mit tilfælde er stoppet) bots fra at være i stand til at indsende spam via kontaktformularen.

ting for dig at prøve #

uanset hvilken ramme din hjemmeside bruger, hvis din kontaktformular bliver kompromitteret af spam prøve disse tilgange:

• Adskil siden og formularen
• Indlæs formularen, når siden er indlæst
• indsend kun formularer programmatisk ved hjælp af button elementer
• Fjern attributten method på formularer og tilføj dem som en del af formularindsendelsen