Samma regel på två ställen: i formuläret för att hjälpa den som skriver, och på servern eller i databasen för att stoppa det som inte får sparas. Du skriver en fälttabell med regel, felmeddelande och plats för kontrollen, klistrar in den i appbyggaren och provar med sex felaktiga inmatningar. Två av dem ska skickas förbi formuläret. Inget av de sex värdena får finnas i appens data efteråt.
Två ställen för kontroll: formuläret och servern
Anta att du bygger en anmälningsapp för en påhittad kurs. Formuläret har namn, e-post, telefon, antal platser och önskat datum. Du provar att lämna namnet tomt, fältet blir rött och knappen gör ingenting. Det ser färdigt ut. Men det du har sett är bara den ena av två kontroller.
MDN:s genomgång av formulärvalidering skiljer på dem: kontroll i webbläsaren kallas klientvalidering, kontroll på servern kallas servervalidering. MDN varnar för att klientvalidering inte ska ses som ett heltäckande säkerhetsskydd. Appar bör kontrollera inskickade data, inklusive säkerhetskontroller, på servern också, eftersom kontrollen i webbläsaren är för lätt att ta sig förbi. MDN skriver dessutom att den som vill kan ändra själva anropet till servern även när formuläret kontrollerar korrekt. W3C:s guide om validering säger samma sak från andra hållet: klientvalidering ger oftast en bättre upplevelse för den som fyller i, men kan kringgås, och därför behöver valideringen göras på servern också.
Det betyder inte att din app saknar servervalidering. Det betyder att du inte kan se det i formuläret. Vad som körs i webbläsaren och vad som körs på servern förklaras i artikeln om frontend och backend. Här räcker det att du beställer regeln på båda ställena och provar det andra stället för sig.
Bestäm regeln per fält innan du beställer
”Lägg till validering” är en beställning som låter appbyggaren välja reglerna. Då vet du inte vad du ska prova. Skriv i stället en tabell med en rad per fält. MDN beskriver de regeltyper som webbläsaren själv kan kontrollera: obligatoriskt fält, minsta och största längd på text, minsta och största värde för tal, och fälttyp som tal eller e-postadress. Tabellen nedan använder samma typer, så att varje regel går att beställa och prova.
| Fält | Regel | Felmeddelande | Var kontrollen ska sitta |
|---|---|---|---|
| Namn | Obligatoriskt, 2–80 tecken efter att mellanslag först och sist tagits bort. | Skriv ditt namn, 2–80 tecken. | Formuläret och servern |
| E-post | Obligatoriskt, ett @ med text före och en domän efter. | Skriv en e-postadress med @, till exempel namn@exempel.se. | Formuläret och servern |
| Telefon | Frivilligt. Om ifyllt: 8–15 siffror sedan mellanslag och bindestreck tagits bort; får börja med +. | Skriv telefonnumret med siffror, till exempel 070-123 45 67. | Formuläret och servern |
| Antal platser | Obligatoriskt heltal från 1 till 6. | Välj mellan 1 och 6 platser. | Formuläret och servern |
| Önskat datum | Obligatoriskt datum som finns, tidigast dagens datum. | Välj ett datum från och med i dag. | Formuläret och servern |
Kolumnen längst till höger säger samma sak på varje rad, och det är avsikten. Formuläret hjälper den som skriver att rätta i tid. Servern eller databasen stoppar det som ändå kommer fram. En regel som bara finns i formuläret är ett råd, inte en spärr.
Felmeddelanden som säger vad som ska rättas och var
Ett rött fält säger att något är fel, inte vad. WCAG 2.2, framgångskriteriet 3.3.1 Identifiering av fel, är på nivå A. Det kräver att det fält som är fel pekas ut och att felet beskrivs i text när appen upptäcker ett inmatningsfel automatiskt. Kriteriet räknar två sorters fel: en obligatorisk uppgift som saknas, och en uppgift som inte har rätt format eller tillåtet värde. Båda finns i tabellen ovan.
Jämför ”Ogiltigt värde” med ”Välj mellan 1 och 6 platser”. Det första kräver att den som fyller i gissar. Det andra går att följa direkt. Skriv därför felmeddelandet i tabellen som en uppmaning: vad ska göras, och gärna med ett exempel. Beställ också att meddelandet står vid fältet och att det som redan är rätt ifyllt finns kvar.
Det finns ett skäl till att skriva meddelandena själv. MDN påpekar att webbläsarens inbyggda felbubblor beror på webbläsarens språkinställning, så att en svensk sida kan visa ett felmeddelande på ett annat språk. Om felet går att uppfatta utan färg och för den som får sidan uppläst provar du med provet ”skicka formuläret fel” i artikeln om tillgänglighet utan kod. Det provet tas inte om här.
Var tillåtande med format: telefon, datum, mellanslag
En regel kan vara för sträng. Då stoppar den riktiga uppgifter, och den som fyller i ger upp. W3C:s guide säger att valideringen ska ta emot olika skrivsätt för samma sorts uppgift så långt det går, och tar telefonnummer som exempel: de skrivs med olika skiljetecken och siffergrupperingar. Därför säger tabellens telefonrad att mellanslag och bindestreck tas bort innan siffrorna räknas. Både 070-123 45 67 och +46 70 123 45 67 ska godtas.
Samma tanke gäller mellanslag först och sist i namn och e-post. Någon som klistrar in sin adress får ofta med ett mellanslag på slutet, och det ska rensas bort, inte ge ett fel. För datum är det enklaste en datumväljare i formuläret, så att den som fyller i inte behöver gissa formen. Servern ska ändå kontrollera att datumet finns och inte ligger bakåt i tiden. Regler för stökiga rader som redan finns i ett kalkylark hör till en annan beställning: se artikeln om att importera Excel till appen.
Kopierbar beställning till appbyggaren
Byt fälten i hakparenteserna mot dina egna och klistra in tabellen under beställningen. Texten beskriver vad du vill ha, inte vad appbyggaren redan gör. Beställningen ber dessutom om ett tillfälligt sätt att skicka ett värde förbi formuläret, så att du kan prova servern utan att skriva kod.
Formuläret [Anmälan] ska följa reglerna i tabellen nedan. Varje regel ska kontrolleras på två ställen: 1. I formuläret, så att felet visas direkt vid fältet. 2. På servern eller i databasen, så att ett värde som bryter mot regeln inte sparas, även om det skickas utan formuläret. Felmeddelandena ska stå i text vid rätt fält, på svenska, med exakt den formulering som står i tabellen. Det som redan är rätt ifyllt ska finnas kvar efter ett fel. Om någon regel bryts ska ingenting sparas, inte heller de fält som var rätt. Ta bort mellanslag först och sist i textfält. Ta bort mellanslag och bindestreck i [Telefon] innan siffrorna kontrolleras. Lägg bara i testversionen in två tillfälliga knappar som skickar var sin anmälan direkt till servern, utan formulärets kontroller: "Testa servern: antal" skickar [Antal platser] = 99. "Testa servern: datum" skickar [Önskat datum] = gårdagens datum. I varje anrop ska alla övriga fält ha giltiga påhittade uppgifter. Skicka anropen separat och visa serverns svar för vart och ett. Förklara utan kodord var serverkontrollen sitter. Ändra inget annat i appen. [Klistra in fälttabellen här]
Läs svaret innan du provar. Säger appbyggaren att kontrollen bara finns i formuläret, eller kan den inte förklara var serverkontrollen sitter, har du redan svaret på provets viktigaste fråga. Be då om serverkontrollen igen innan du går vidare.
Provet: sex felaktiga inmatningar, varav två förbi formuläret
Gör provet i testversionen av din egen app och bara med påhittade uppgifter, till exempel namnet Test Testsson och adressen test@exempel.se. Räkna först hur många anmälningar som finns i appens lista eller tabellvy och skriv ner siffran. Efter provet ska siffran vara densamma.
Räkna anmälningarna efter varje försök och igen när hela provet är klart. Antalet ska vara oförändrat efter alla sex. En post med 99 platser eller gårdagens datum visar att motsvarande serverkontroll inte fungerar, även om steg 1 till 4 såg rätt ut. Provet verifierar serverns regler för antal och datum; prova övriga fält separat på samma sätt innan du bedömer hela fälttabellen som kontrollerad. Skicka sedan en helt korrekt anmälan med telefonnumret skrivet 070-123 45 67. Den ska sparas, och siffran ska öka med ett. Om den avvisas, kontrollera felbeskedet och om någon regel är för sträng. Be till sist appbyggaren ta bort båda testknapparna och kontrollera att de inte finns i den publicerade appen. Spara provet som en rad i din provlista, så att du kör det igen när formuläret ändras.
Provet är gjort för testversionen av en app du själv äger, med påhittade uppgifter. Det kräver inga verktyg, och det ska inte riktas mot någon annans app eller tjänst.
Validering är inte behörighet eller skydd mot skadlig kod
Ett godkänt prov visar att fel format stoppas. Det visar inte vem som får spara, läsa eller ändra en anmälan. Det är en fråga om behörighet, och den provas för sig enligt guiden om behörigheter i Lovable. Ett namnfält som tar emot 2–80 tecken kan också innehålla text som är skriven för att skada, och den här sidan lovar inget skydd mot sådan inmatning. Hur utvecklare hanterar den risken beskrivs i artikeln om SQL-injektion i AI-genererad kod.
Två saker ligger också utanför. Vart ett meddelande från ett kontaktformulär tar vägen, och hur du hittar det, provas i guiden om kontaktformulär i AI-appen. Och regler för rader som läses in från en fil, inte skrivs i ett formulär, finns i importartikeln ovan.
Källor och avgränsning
Primärkällorna kontrollerades 26 oktober 2026. MDN används för skillnaden mellan klient- och servervalidering, varningen om att klientvalidering går att kringgå, regeltyperna och webbläsarens felbubblor. W3C:s guide används för servervalidering och för tillåtande format. WCAG 3.3.1 används för kravet på felmeddelanden i text. Fälttabellen, beställningen och provets facit är redaktionella förslag. Ingen app har provkörts, och sidan påstår inget om vad en viss appbyggare gör som standard.
- MDN: Client-side form validation – klient- och servervalidering, regeltyper och felbubblor.
- W3C WAI: Validating Input – servervalidering och tillåtande format.
- W3C: Understanding SC 3.3.1 Error Identification – fel ska pekas ut och beskrivas i text.