Någon skickar in ditt formulär med en ogiltig e-postadress. Formuläret godtar den. Välkomstmejlet studsar. Personen hör aldrig av dig. En annan person skickar in med obligatoriska fält som saknas. Formuläret går ändå igenom. Ditt team får ofullständig data. Båda felen beror på att valideringen saknas eller är fel.
Validering betyder att du kontrollerar att formulärdata är giltig innan du tar emot den. Det sker på två ställen: i webbläsaren och på servern. Båda spelar roll. Den här artikeln går igenom hur validering fungerar, varför du behöver båda och vanliga misstag.
Vad är validering?
Validering kontrollerar att data i ett formulär uppfyller dina krav. Obligatoriska fält har värden. E-postfält innehåller ett @-tecken. Telefonfält innehåller bara siffror. Filuppladdningar håller sig under storleksgränsen.
Utan validering kommer dålig data in i ditt system. Din backend kraschar. Din e-posttjänst avvisar meddelanden. Du slösar tid på att städa upp smutsig data.
Validering sker på två ställen: på klientsidan (i webbläsaren, före inskick) och på serversidan (på din server, efter inskick). Båda behövs.
Validering på klientsidan
Webbläsaren kan kontrollera formulärdata innan den skickas. HTML har inbyggda attribut för validering. JavaScript kan också validera.
HTML-validering
<input type="email" required> kontrollerar att fältet har ett värde och ser ut som en e-postadress. Webbläsaren visar ett felmeddelande om användaren försöker skicka ett ogiltigt formulär.
HTML-attribut för validering är bland annat required som kräver att fältet har ett värde, min/max för tal som håller värden inom ett intervall, minlength/maxlength som styr antalet tecken, pattern som matchar reguljära uttryck och type som kontrollerar själva fälttypen. Till exempel kontrollerar type="email" formatet medan type="number" avvisar indata som inte är siffror.
HTML-validering fungerar direkt utan JavaScript och ger bra felmeddelanden från webbläsaren, med mobiltangentbord som anpassas efter fälttypen. Nackdelarna är att webbläsarens felmeddelanden är generiska och ibland oklara, att du inte kan anpassa dem utan JavaScript och att olika webbläsare visar olika meddelanden.
JavaScript-validering
För mer kontroll kan du validera med JavaScript med function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } och form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. Med JavaScript-validering kan du skriva egna regler, visa egna felmeddelanden och validera fält medan användaren skriver, för validering i realtid. Nackdelar är att det kräver JavaScript (inte tillförlitligt för säkerhet), att det kräver mer kod att underhålla och att fel kan visas innan användaren skrivit klart om du validerar vid input-händelsen.
Validering på serversidan
När formuläret har skickats kontrollerar servern datan igen. Det är här den verkliga säkerheten finns.
Lita aldrig på validering på klientsidan. Någon kan stänga av JavaScript. Någon kan fånga upp förfrågan och ändra datan. Någon kan använda curl eller ett annat verktyg för att skicka dålig data utan att alls gå via ditt formulär.
Validering på serversidan är det enda skydd du har. Den är inte valfri.
När servern tar emot inskicket ska du kontrollera att obligatoriska fält finns, validera format för e-post, telefon och webbadresser, kontrollera att tal ligger inom förväntade intervall, verifiera att filuppladdningar har rätt typ och storlek, säkerställa att datan inte är för lång och sanera datan för att förhindra injektionsattacker. Om valideringen misslyckas skickar du ett felsvar, så att formuläret inte behandlas och användaren får veta vad som är fel. Validering på serversidan är långsammare eftersom användaren måste vänta på svar, men den är tillförlitlig och säker, så gör den alltid.
När du ska använda vilken typ av validering
Validering på klientsidan är till för användarupplevelsen. Den talar direkt om för användaren om något är fel. Hen behöver inte skicka formuläret för att få veta att en e-postadress är ogiltig.
Validering på serversidan är till för dataintegritet och säkerhet. Den ser till att dålig data aldrig kommer in i ditt system.
Använd båda. Klientsidan för snabbhet och återkoppling. Serversidan för trygghet och säkerhet.
Vanliga valideringsmisstag
Att bara validera på klientsidan
Någon stänger av JavaScript och din validering är borta. Någon använder curl för att POST:a dålig data och din validering körs aldrig. Du får skräp i databasen.
Validera alltid på servern. Klientsidan är ett extra.
Att validera för strikt
Din e-postvalidering är så strikt att riktiga adresser misslyckas. Din telefonvalidering godtar bara amerikanskt format och avvisar internationella nummer. Ditt namnfält avvisar bindestreck, apostrofer och andra giltiga tecken.
Testa din validering mot verkliga data. Be användare från andra länder testa. Gör valideringsreglerna så generösa som möjligt och fånga ändå dålig data.
Att inte visa tydliga felmeddelanden
"Ogiltig indata." Vad är ogiltigt? Vilket fält? Vad ska användaren göra?
Felmeddelanden måste vara specifika: "E-postadressen måste vara mellan 5 och 254 tecken." "Telefonnumret måste ha 10 siffror." "Lösenordet måste innehålla minst en siffra."
Visa felet bredvid fältet som orsakade det. Göm inte fel i en sammanfattningslista där användaren måste leta efter dem.
Att validera känslig data på klienten
Skicka inte kreditkortsnummer eller lösenord genom validering på klientsidan. Visa dem inte i webbläsarens konsol. Logga dem inte.
Validera känslig data bara på servern, över HTTPS.
Att inte validera filuppladdningar
Någon laddar upp en fil på 100 megabyte. Din server får slut på lagringsutrymme. Någon laddar upp en körbar fil. Din server drabbas av ett virus.
Validera filtyp och storlek på servern. Kontrollera att filen verkligen är den typ den säger sig vara. Lita inte bara på filändelsen eller MIME-typen.
Validering i realtid eller vid inskick
Validering i realtid kontrollerar varje fält medan användaren skriver. Användaren ser ett felmeddelande direkt om hen skriver något fel. Hen kan rätta det med en gång.
Nackdel: Om du visar fel för tidigt blir användaren frustrerad. Visa fel först när användaren lämnar fältet (vid blur-händelsen), inte medan hen fortfarande skriver.
Validering vid inskick kontrollerar allt när formuläret skickas. Användaren fyller i hela formuläret och ser sedan alla fel på en gång.
Nackdel: Användaren måste gå tillbaka och rätta fel efter att hen redan skickat. Det avbryter flödet.
Bästa praxis: Validera vid blur (när användaren lämnar ett fält) för återkoppling i realtid. Validera vid inskick som en sista kontroll. Visa alla fel samtidigt om något misslyckas.
Validering för specifika fälttyper
Validering av e-post
Fullständig validering av e-post är komplex (RFC 5322 är 60 sidor), så i de flesta fall räcker det att kontrollera att värdet innehåller ett @ och en domän med const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Det fångar de flesta ogiltiga adresser utan att vara så strikt att riktiga adresser misslyckas.
Validering av telefonnummer
Telefonformat varierar mellan länder. Det amerikanska formatet är (123) 456-7890, det brittiska är +44 20 7946 0958 och Tyskland använder +49 30 123456. Godta internationellt format, ta bort tecken som inte är siffror på servern och lagra telefonnumret som en sträng i stället för ett tal, så att inledande nollor i vissa länder bevaras.
Validering av lösenord
Ett bra lösenord är långt (minst 12 tecken) och svårt att gissa. Kräv inte specialtecken eller blandning av versaler och gemener, eftersom de reglerna frustrerar användare och inte förbättrar säkerheten. Bra lösenordskrav är minst 12 tecken och att undvika vanliga mönster (som "123456" eller användarens namn). Använd en lösenordsmätare som visar användaren hur starkt lösenordet är.
Validering av datum
Kontrollera att datumet ligger i framtiden eller det förflutna efter behov. Ett anmälningsformulär till ett evenemang ska avvisa datum som har passerat. Ett formulär för födelsedatum ska avvisa datum i framtiden.
Så hanterar WEMASY formulärvalidering
WEMASY-formulär har inbyggd validering på klientsidan (obligatoriska fält, e-postformat med mera) för direkt återkoppling. När formulär skickas validerar WEMASY:s servrar all data igen innan den behandlas. Då får användarna snabb återkoppling och din data är skyddad.
Se valideringsfunktionerna i din WEMASY-plan.