3 Commits

Author	SHA1	Message	Date
Claude	d3cae27fa4	Bilagor ut ur händelseloggen — referens och hash i stället för inbäddat ... Foton, video och instrumentbilder låg som data-URL:er inne i händelserna. Det drabbade allt som läser loggen: synken drog med hela bildmassan var femtonde sekund, kundvyn likaså, och en säkerhetskopia av loggen var i praktiken en kopia av alla foton. Nu ligger innehållet utanför händelsen och loggen bär en referens med innehållets SHA-256. Det försvagar inte bevisvärdet utan stärker det: hashen står i den append-only-skyddade loggen, så en bild som bytts ut går att upptäcka. Tidigare låg bilden i loggen och måste helt enkelt tros på. Innehållet kontrolleras mot hashen varje gång det lämnas ut — stämmer det inte svarar tjänsten 409 i stället för att visa bilden. Innehållsadresserat, så samma foto som dokumenteras två gånger lagras en gång. Två lägen: databas (bytea, fungerar överallt utan konfiguration) och s3 (AWS, MinIO, Ceph). Signeringen är egen — SigV4 för PUT och GET — i stället för molnleverantörens SDK, eftersom två operationer inte motiverar tiotals megabyte beroenden i en bild som annars bara har pg-drivrutinen. Den korsverifieras bit för bit mot botocore i testerna. Det avslöjade en riktig bugg direkt: host-huvudet saknade portnummer, vilket hade fungerat mot AWS men avvisats av all självhostad S3. Kodningen av objektnycklar kanoniseras medvetet inte. S3 följer andra URL-regler än övriga AWS-tjänster och en felgissad regel ger signaturer som ser rimliga ut men avvisas. I stället begränsas hink och prefix till tecken som aldrig behöver kodas — då finns ingen regel att gissa fel på. Delningsgränsen gäller även bilagor: en bilaga lämnas bara ut via en delningslänk om händelsen den hör till är synlig på den nivån, så den skannade arbetsordern nås aldrig via kundlänken. Uppladdningen sker på ett enda ställe — sidans egna skicka() flyttar innehållet innan händelsen skrivs, så ingen panel behövde ändras. Misslyckas det, eller saknas server som i lokalt läge, bäddas det in precis som förut. Dokumentationen får aldrig gå förlorad för att nätet ligger nere, och äldre händelser med inbäddad data-URL fortsätter fungera för alltid eftersom loggen är append-only. Verifierat: 96 vitest-tester (varav 9 nya för signering och innehållsadressering), typkontroll, eslint, OpenAPI-validering, terraform fmt och referenskontroll, samt integrationstest mot riktig Postgres med 13 nya kontroller — bland annat att ett manipulerat innehåll upptäcks och inte lämnas ut, och att kundlänken når fotot men inte arbetsordern. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-04 11:28:52 +00:00
Claude	a7574015b1	Åtkomsthärdning: kontospärr, omedelbar återkallelse, takt på inloggning ... Två luckor från genomgången, båda i auth. En utfärdad token gällde sina tolv timmar ut. Det fanns dessutom inget sätt att stänga av ett konto alls — en person som slutade behöll åtkomsten till organisationens ärenden. Nu bär token en version, och varje autentiserat anrop slår upp kontot och kontrollerar att det är aktivt och att versionen stämmer. Det kostar ett uppslag på primärnyckeln per anrop och ger i gengäld omedelbar verkan i stället för en avstängning som börjar gälla någon gång i morgon. Administratören stänger av och öppnar konton i användarlistan. Att stänga av höjer token-versionen, så pågående sessioner upphör direkt; öppnas kontot igen förblir de gamla token döda. Ingen kan stänga av sig själv och organisationsgränsen gäller. Var och en kan dessutom logga ut på alla enheter — vägen ut när en telefon tappats bort. Händelseloggen rörs aldrig: historiken är fortfarande knuten till den som utförde arbetet. Lösenord kunde gissas i obegränsad takt. Spärren ligger nu i databasen, inte i minnet, så den håller bakom flera repliker: 10 misslyckade försök per konto och 30 per källadress inom 15 minuter. Spärren gäller kontot även vid rätt lösenord — annars kunde den kringgås av den som till slut gissar rätt. Andra konton påverkas inte. Inget lösenord lagras, bara att ett försök skedde och om det lyckades, och rader äldre än ett dygn städas bort i skrivvägen. Ett avstängt konto räknas som misslyckat försök så att svarstiden inte avslöjar vilka konton som finns. Verifierat: 87 vitest-tester, typkontroll, eslint, OpenAPI-validering och integrationstest mot riktig Postgres med 13 nya kontroller — rollstyrning, självavstängning, organisationsgränsen, att en utfärdad token dör direkt, att den förblir död efter återöppning, logga-ut-alla samt att spärren slår till, gäller även rätt lösenord och inte smittar andra konton. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-03 22:38:55 +00:00
Claude	19796bec70	Terraform blir enda vägen, och backup ett obligatoriskt val ... Kustomize- och Argo CD-vägen är borttagen. Den beskrev samma system en gång till och kunde inte köras samtidigt som Terraform utan att de motarbetade varandra — selfHeal återställde det Terraform ändrade och prune tog bort det Terraform skapade. Kvar utanför Terraform är bara postgres-init.sql, som läses av både definitionen och integrationstestet så att schemat inte kan glida isär från det som testas. Säkerhetskopieringen var en förhoppning: en StatefulSet med en volym och ingen kopia. Går volymen förlorad är det inte "data" som försvinner utan varje ärendes bevisvärde — vad som kontrollerades, av vem, när, med vilken evidens — och det går inte att återskapa i efterhand. databas_lage är därför ett obligatoriskt val utan standardvärde: extern managerad Postgres, leverantörens backup och PITR (rekommenderat i produktion) cnpg CloudNativePG i klustret: basbackup 02:30, kontinuerlig WAL-arkivering till objektlagring, PITR och failover inbyggd en volym, ingen backup — spärras av en precondition när miljön är produktion Preconditions fångar felkonfiguration vid plan i stället för vid drift: extern utan anslutning, cnpg utan backupmål eller nycklar, inbyggd i produktion. Driftsättningen är nu två åtskilda flöden. Publicera bygger och taggar bilderna vid varje main-push; Driftsätt startas för hand med en tagg mot en GitHub-miljö som kan kräva godkännande, kör fmt/init/validate/plan/ apply, skriver ut kartan och rökkontrollerar hälsa och API-spec. En bild i registret är inte samma sak som en bild som kör. Rollback är att köra Driftsätt igen med en tidigare tagg. CI kör dessutom terraform validate på varje PR — den kontroll jag inte kunde köra själv. Två fel hittade vid egengranskning av definitionen: schemafilen delades på semikolon, vilket hade klippt itu plpgsql-funktionen med append-only-triggern (nu hela filen via postInitApplicationSQLRefs), och null-satta fält i kubernetes_manifest utelämnas nu i stället. Verifierat: 87 vitest-tester, typkontroll, eslint, OpenAPI-validering, terraform fmt, statisk referenskontroll av modulen och integrationstest mot riktig Postgres. terraform validate kunde inte köras här — registry.terraform.io är blockerad av sessionens egress-policy, därav CI-jobbet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt	2026-08-03 22:16:52 +00:00