Fleranvändarsystem och idempotens

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer är **multitenant**: en gateway kan betjäna många arbetsytor från en databas samtidigt som deras data hålls åtskilda. Två mekanismer gör det säkert — **Postgres radnivåsäkerhet (RLS)** för läs-/skrivisolering, och en **idempotenslager** så att försök igen och återställning av tur aldrig duplicerar en verklig bieffekt. **Nivå:** Radnivåsäkerhet multitenant-isolering är begränsad av det betalda **Företag** nivå — ingår inte i den kostnadsfria/Community-plattformen; idempotenslagret är en del av kärnan. ## Hyresgästisolering med radnivåsäkerhet Isolation genomförs på databasen, inte bara i applikationskoden. AiHummer kör frågor genom en **begränsad Postgres-roll** (`aihummer_app`) som har RLS-policys tillämpade, så databasen själv avvisar rader som inte tillhör den aktiva hyresgästen. RLS är **anmäla sig**. Du aktiverar det genom att ge gatewayen en andra anslutningssträng för den begränsade rollen: ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > För värd-native installationer sätter installationsprogrammet `AIHUMMER_DB_APP_URL` > automatiskt, så RLS är på som standard i en vanlig installation. Om > variabeln saknas kör gatewayn endast på ägarpoolen och RLS är inte > aktiv. ### Per-hyresgästanpassad avgränsning Inom den begränsade rollen är varje begäran begränsad till sin hyresgäst: gatewayen ställer in den aktuella hyresgästkontexten på anslutningen så att RLS-policyer löses mot rätt arbetsyta. `WHERE tenant_id = …` filter är inte handgjorda överallt; policyn genomförs centralt, vilket betyder att ett missat filter inte kan läcka en annan hyresgästs rader. ### System / kringgående läge Viss arbetsbelastning är legitimt tvärs över hyresgäster — bakgrundsarbetare, schemaläggare och underhållsjobb som fungerar över hela instansen. Dessa körs i en **system / kringgående läge** så att de kan se vad de behöver. Bypass är reserverat för betrodda interna medarbetare, inte för förfrågningshanteringsvägar. > [!WARNING] > **Migrationer körs alltid på ägarpoolen**, aldrig under den begränsade rollen. > Ägarkopplingen har privilegier att ändra schema och tillämpa RLS > policyer; den begränsade rollen gör det medvetet inte. Behåll de två anslutningarna > strängar distinkta och ge `aihummer_app` ge endast rollen det den behöver. ## Idempotenta sidoeffekter En tur kan producera verkliga bieffekter: skicka e-post, posta ett meddelande tillbaka till en kanal. Om en tur försöks igen — på grund av ett tillfälligt fel, eller för att gatewayen startade om mitt i turen och återställning spelar upp den — måste dessa bieffekter **inte** hända två gånger. AiHummer garanterar detta med två samverkande delar. ### En CV-stabil huvudboknyckel Varje biverkning registreras mot en **återuppta-stabilt huvudboknyckel**: en nyckel som härleds deterministiskt från turen, så en uppspelning av samma tur beräknar *samma* nyckel istället för en ny. Boken kommer ihåg vilka nycklar som redan har åtgärdats. ### En bieffektsbarriär Innan en effekt såsom **post** eller **kanal-skicka** utförs, passerar det genom en **biverkningsbarriär** som kontrollerar huvudboken. Om denna nyckel redan har utlösts, kortsluter barriären och effekten hoppas över; om inte, körs effekten och nyckeln registreras. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Resultatet är **exakt-en-gång externt beteende även om leverans är minst-en-gång internt**. Omförsök är säkra av konstruktion, vilket är det som möjliggör vändåterställning (se [Pålitlig leverans och återhämtning](/sv/v1.0/architecture/delivery-outbox)) spela upp en avbruten tur utan att en kund får samma e-post eller samma svar två gånger. > [!TIP] > Detta är anledningen till att AiHummer kan erbjuda garanterad leverans och automatisk återhämtning av turer > utan den vanliga risken för dubbla meddelanden — idempotens är grunden > leveransgarantierna är byggda på. ## Vart härnäst - Den körningstid som driver en tur: [Gateway- och turbinmotor](/sv/v1.0/architecture/gateway-turn-engine). - Hur svar returneras exakt en gång: [Pålitlig leverans och återhämtning](/sv/v1.0/architecture/delivery-outbox).