Multitenancy og 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 er **multilejer**: én gateway kan servicere mange arbejdsområder fra én database, samtidig med at deres data holdes adskilt. To mekanismer gør det sikkert — **Postgres række-niveau sikkerhed (RLS)** til læse-/skrive-isolation, og en **idempotenslag** så genforsøg og vending af fejl aldrig fordobler en virkelig bivirkning. **Dyreklasse:** Row-Level Security multitenant-isolering er begrænset af den betalte **Foretagende** niveau — ikke en del af den gratis/Community-platform; idempotenslaget er en del af kernen. ## Lejerisolering med række-niveau sikkerhed Isolation håndhæves på databasen, ikke kun i applikationskoden. AiHummer kører forespørgsler gennem en **begrænset Postgres-rolle** (`aihummer_app`) der har RLS-politikker anvendt, så selve databasen afviser rækker, der ikke tilhører den aktive lejer. RLS er **tilmelde sig**. Du aktiverer det ved at give gatewayen en anden forbindelsesstreng til den begrænsede rolle: ```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] > For værts-native installationer sætter installationsprogrammet `AIHUMMER_DB_APP_URL` > automatisk, så RLS er slået til som standard i en standardimplementering. Hvis > variablen er fraværende, gatewayen kører kun på ejer-poolen, og RLS er ikke > aktiv. ### Per-lejer afgrænsning Inden for den begrænsede rolle er hver anmodning begrænset til sin lejer: gatewayen sætter den aktuelle lejers kontekst på forbindelsen, så RLS-politikker løses i forhold til det rigtige arbejdsområde. `WHERE tenant_id = …` Filtre rulles ikke håndmæssigt overalt; politikken håndhæves centralt, hvilket betyder, at et manglende filter ikke kan lække en anden lejers rækker. ### System / bypass-tilstand Noget arbejde er legitimt tvær-lejer — baggrundsarbejdere, planlæggere og vedligeholdelsesopgaver, der fungerer på tværs af hele instansen. Disse kører i en **system / bypass-tilstand** så de kan se, hvad de har brug for. Bypass er reserveret til betroede interne medarbejdere, ikke til anmodningshåndteringsveje. > [!WARNING] > **Migrationer kører altid på ejerpuljen**, aldrig under den begrænsede rolle. > Ejerforbindelsen har rettighederne til at ændre skema og anvende RLS > politikker; den begrænsede rolle gør det bevidst ikke. Hold de to forbindelser > strenge forskellige og give `aihummer_app` rolle kun hvad den har brug for. ## Idempotente bivirkninger En tur kan producere bivirkninger i den virkelige verden: sende mail, poste en besked tilbage til en kanal. Hvis en tur forsøges igen — på grund af en midlertidig fejl, eller fordi gatewayen genstartede midt i turen og gendannelsen afspiller den — skal disse bivirkninger **ikke** ske to gange. AiHummer garanterer dette med to samarbejdende dele. ### En CV-stabil hovedbogsnøgle Hver bivirkning registreres mod en **resumé-stabil hovedbogsnøgle**: en nøgle, der er afledt deterministisk fra turen, så en gentagelse af samme tur beregner den *samme* nøgle i stedet for en ny. Kladdebogen husker, hvilke nøgler der allerede er blevet handlet på. ### En bivirkningsbarriere Før en effekt som **mail** eller **kanal-send** udføres, passerer det gennem en **bivirkning barriere** der tjekker hovedbogen. Hvis denne nøgle allerede er udløst, kortslutter barrieren, og effekten springes over; hvis ikke, kører effekten, og nøglen registreres. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Resultatet er **præcist-en-gang ekstern adfærd selvom levering er mindst-en-gang internt**. Genforsøg er sikre af konstruktion, hvilket er det, der gør det muligt at vende tilbage til genopretning (se [Pålidelig levering og genopretning](/da/v1.0/architecture/delivery-outbox)) genafspil en afbrudt tur uden at en kunde modtager den samme e-mail eller det samme svar to gange. > [!TIP] > Dette er grunden til, at AiHummer kan tilbyde garanteret levering og automatisk vending. > uden den sædvanlige risiko for dobbeltmeddelelser — idempotens er fundamentet > leveringsgarantierne er bygget på. ## Hvor til næste - Den runtime, der driver et sving: [Gateway og drejemotor](/da/v1.0/architecture/gateway-turn-engine). - Hvordan svar returneres præcist én gang: [Pålidelig levering og genopretning](/da/v1.0/architecture/delivery-outbox).