Slet sikkert: begræns massehandlinger og gør fejl mulige at rette

Find handlingerne, hvor ét klik kan få stor virkning

Sletning er det tydelige eksempel, men samme mønster gælder masseændring af status, lukning af brugere, flytning mellem virksomheder, genberegning af fakturaer og udsendelse til mange modtagere. Skriv for hver handling, hvad der ændres, hvor bredt den kan ramme, og om virkningen også fortsætter i filer, integrationer, jobs eller andre datatabeller.

Lad serveren beregne en konkret forhåndsvisning

Før en bred handling udføres, bør serveren genberegne mål og omfang ud fra den aktuelle bruger, virksomhed og de valgte filtre. Vis resultatet som en forståelig forhåndsvisning: navn, periode, antal poster, relaterede data, eksterne følger og hvad der kan gendannes. OWASP beskriver samme princip som, at brugeren skal kunne se og anerkende de oplysninger, der er væsentlige for handlingen.

• Skriv objektet: “Kunde Nordvind ApS” er bedre end “valgt post”.
• Skriv omfanget: Vis eksempelvis antal sager, filer, tidsregistreringer og aktive brugere, der bliver berørt.
• Skriv virkningen: Skeln mellem arkivering, papirkurv, permanent sletning og ekstern afsendelse.
• Advar om uafklarede relationer: Stop handlingen, hvis appen ikke kan beregne konsekvensen sikkert.

Vælg en bekræftelse, der passer til risikoen

W3C's WCAG-kriterium om fejlforebyggelse for vigtige dataændringer peger på tre brugbare sikkerhedsnet: handlingen kan gøres om, input kan kontrolleres med mulighed for rettelse, eller brugeren kan gennemgå og bekræfte oplysningerne før afslutning. I behøver ikke lægge maksimal friktion på alt; reservér de stærke stop til de handlinger, hvor fejlen er dyr eller svær at rette.

Håndhæv hele beslutningen på serveren

En skjult knap er ikke adgangskontrol. Endpointet eller databasekaldet skal afvise som standard og kontrollere rettigheden på hver request. Knyt godkendelsen til den konkrete handling og dens afgørende data, og læg den sidste kontrol umiddelbart før ændringen udføres.

1. Identitet: Er sessionen gyldig, og kræver risikoen en nyere loginbekræftelse?
2. Rettighed: Må denne bruger udføre netop denne handling — ikke bare åbne administrationssiden?
3. Ejerskab: Tilhører hvert mål den virksomhed eller konto, requestet gælder for?
4. Omfang: Matcher den aktuelle optælling den forhåndsvisning, brugeren accepterede? Stop ved uventet vækst.
5. Gentagelse: Kan dobbeltklik, timeout eller retry udføre handlingen to gange? Brug et unikt handlings-id, hvor gentagelse ellers er farlig.

Vælg transaktion, batch eller job efter arbejdets størrelse

Små, sammenhængende databaseændringer kan ofte samles atomisk: enten gennemføres alle trin, eller ingen gør. PostgreSQL-transaktioner og Firestore-transaktioner eller batches tilbyder denne egenskab inden for deres egne rammer. Store sletninger, filoperationer og eksterne kald passer derimod ofte bedre som et kontrolleret baggrundsjob med status og mulighed for genoptagelse.

• PostgreSQL: Definér bevidst om en relation skal blokere sletning, sættes til en ny værdi eller følge med via en foreign key-policy som ON DELETE.
• Cloud Firestore: Sletning af et dokument sletter ikke automatisk dokumenterne i dets subcollections. De skal kortlægges og håndteres særskilt.
• Store mængder: Arbejd i afgrænsede portioner med optalt fremdrift, fejlstatus og en regel for genkørsel. Store Firestore-sletninger kan påvirke svartiden.
• Eksterne systemer: En database-transaktion kan ikke rulle en allerede sendt email eller en ekstern API-handling tilbage. Gem mellemstatus og afstem resultatet.

Planlæg gendannelse uden at gemme alt for evigt

Soft delete, papirkurv og backup løser forskellige problemer. Soft delete kan give hurtig brugerfortrydelse. En backup kan genskabe et større datasæt efter en hændelse. Ingen af delene må blive en skjult undskyldning for at beholde persondata uden en aftalt frist og et sagligt behov.

• Beskriv vinduet: Hvem kan gendanne hvad, hvor længe og fra hvilket miljø?
• Beskyt papirkurven: En almindelig bruger må ikke kunne læse andre kunders slettede data.
• Test hele objektet: Gendannelse af en kunde skal også håndtere de relationer, filer og statusser, som driften kræver.
• Adskil log og indhold: Revisionssporet kan beskrive, at noget blev slettet, uden at bevare hele det slettede indhold.

Test de fejl, som den pæne brugerrejse skjuler

• Forkert virksomhed: En gyldig administrator ændrer mål-id'et til en anden kundes data.
• Ændret omfang: Nye poster kommer til mellem preview og udførelse.
• Dobbelt handling: Brugeren dobbeltklikker, browseren retryer, eller svaret forsvinder efter serveren har udført arbejdet.
• Afbrudt job: Processen stopper midt i batch 4 og startes igen.
• Skjulte relationer: Et parent-objekt slettes, mens børn, filer, søgeindeks eller integrationer bliver tilbage.
• Samtidig ændring: En anden bruger redigerer data under sletningen.
• Gendannelse: En anden ansvarlig følger runbooken og bekræfter data og brugeradgang efter restore.

Typiske fejl

• Kun knappen er beskyttet: API-kaldet kan udføres direkte af en bruger, som ikke måtte se knappen.
• Bekræftelsen er vag: “Er du sikker?” fortæller ikke navn, antal, periode eller følgevirkning.
• Klientens antal stoles på: En manipuleret eller forældet browserværdi bliver brugt som serverens afgrænsning.
• Parent slettes først: Relaterede dokumenter eller filer mister deres synlige tilknytning og bliver sværere at finde.
• Et stort loop kører i webrequestet: Timeout efterlader uklar status og en proces, som ikke er sikker at genkøre.
• Backup forveksles med fortryd: Ingen kender gendannelsestid, omfang eller konsekvens for data, der er ændret siden.

Tjekliste før sletning og massehandlinger åbnes

• ☐ Handlinger med stor konsekvens er navngivet og risikovurderet.
• ☐ Serveren beregner mål, omfang og relationer til en konkret forhåndsvisning.
• ☐ Brugeren kan se navn, antal, periode, følgevirkning og gendannelsesmulighed.
• ☐ Bekræftelsen passer til risikoen og er tilgængelig med tastatur og hjælpemidler.
• ☐ Identitet, rettighed, virksomhed og mål kontrolleres igen ved udførelse.
• ☐ Uventet ændring i omfang stopper eller kræver en ny bekræftelse.
• ☐ Små sammenhængende ændringer er atomiske, hvor datalageret understøtter det.
• ☐ Store jobs har status, afgrænsede batches, sikker genkørsel og stopkriterier.
• ☐ Relationer, subcollections, filer, søgeindeks og integrationer er kortlagt.
• ☐ Dobbeltklik, timeout, samtidighed, forkert kunde og afbrudt job er testet.
• ☐ Revisionsspor og en realistisk gendannelsesvej er afprøvet.

Relaterede guides