Wielodostępność i niezmienność

# 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 jest **wielodostępny**: jedna bramka może obsługiwać wiele obszarów roboczych z jednej bazy danych, jednocześnie utrzymując ich dane oddzielnie. Dwa mechanizmy zapewniają bezpieczeństwo tego — **Bezpieczeństwo na poziomie wiersza w Postgres (RLS)** do izolacji odczytu/zapisu oraz **warstwa idempotentności** tak aby ponowne próby i odzyskiwanie po obrocie nigdy nie powodowały powielenia rzeczywistego efektu ubocznego. **Poziom:** Izolacja wielodostępowa na poziomie wiersza (Row-Level Security) jest ograniczona przez płatność **Przedsiębiorstwo** poziom — nie jest częścią darmowej/platformy społecznościowej; warstwa idempotentności jest częścią rdzenia. ## Izolacja najemcy z użyciem zabezpieczeń na poziomie wiersza Izolacja jest wymuszana na poziomie bazy danych, a nie tylko w kodzie aplikacji. AiHummer uruchamia zapytania przez **ograniczona rola Postgresa** (`aihummer_app`) która ma zastosowane polityki RLS, więc sama baza danych odrzuca wiersze, które nie należą do aktywnego najemcy. RLS jest **dobrowolny udział**Aktywujesz go, podając bramie drugi ciąg połączenia dla ograniczonej roli: ```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] > Dla instalacji natywnych na hoście instalator ustawia `AIHUMMER_DB_APP_URL` > automatycznie, więc RLS jest domyślnie włączony w standardowej instalacji. Jeśli > zmienna jest nieobecna, brama działa tylko na puli właściciela i RLS nie jest > aktywny. ### Zakres dla poszczególnych najemców W ramach ograniczonej roli każde żądanie jest przypisane do swojego najemcy: brama ustawia bieżący kontekst najemcy na połączeniu, aby polityki RLS były rozwiązywane w odniesieniu do właściwego środowiska pracy. `WHERE tenant_id = …` filtry nie są ręcznie tworzone wszędzie; polityka egzekwuje to centralnie, co oznacza, że pominięty filtr nie może ujawnić wierszy innego najemcy. ### System / tryb omijania Niektóre prace są legalnie międzydzierżawcze — pracownicy w tle, harmonogramy i zadania konserwacyjne, które działają w całej instancji. Te działają w **system / tryb obejścia** aby mogli zobaczyć to, co muszą. Obejście jest zarezerwowane dla zaufanych pracowników wewnętrznych, a nie dla ścieżek obsługujących żądania. > [!WARNING] > **Migracje zawsze uruchamiają się na pulach właściciela**, nigdy w ramach ograniczonej roli. > Połączenie właściciela ma uprawnienia do zmiany schematu i stosowania RLS > polityki; rola ograniczona celowo tego nie robi. Zachowaj oba połączenia > ciągi odrębne i przyznaj `aihummer_app` rola tylko to, czego potrzebuje. ## Idempotentne skutki uboczne Tura może wywoływać skutki uboczne w świecie rzeczywistym: wysyłanie poczty, zamieszczanie wiadomości z powrotem na kanale. Jeśli tura jest powtarzana — z powodu błędu przejściowego lub dlatego, że brama ponownie uruchomiła się w trakcie tury i odtwarzanie ją powtarza — te skutki uboczne muszą **nie** zdarzyć się dwukrotnie. AiHummer gwarantuje to dzięki dwóm współpracującym elementom. ### Klucz księgi rachunkowej stabilny przy wznawianiu Każdy efekt uboczny jest rejestrowany w odniesieniu do **wznowienie-stabilny klucz księgi**: klucz, który jest deterministycznie wyprowadzany z tury, więc ponowne odtworzenie tej samej tury oblicza *ten sam* klucz, a nie nowy. Księga pamięta, które klucze zostały już użyte. ### Bariera skutków ubocznych Przed efektem takim jak **poczta** lub **wysyłanie-kanału** jest wykonywany, przechodzi przez **bariera skutków ubocznych** który sprawdza księgę główną. Jeśli ten klucz został już uruchomiony, bariera zostaje zablokowana, a efekt jest pomijany; jeśli nie, efekt zostaje wykonany, a klucz zostaje zatwierdzony. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Wynik jest **dokładnie-jednokrotne zewnętrzne zachowanie, mimo że dostarczanie wewnętrznie jest co najmniej raz**. Ponowne próby są bezpieczne z definicji, co pozwala na odzyskiwanie obrotów (zobacz [Niezawodna dostawa i odzyskiwanie](/pl/v1.0/architecture/delivery-outbox)) odtwórz przerwaną turę bez wysyłania klientowi tego samego e-maila lub tej samej odpowiedzi dwukrotnie. > [!TIP] > Dlatego AiHummer może oferować gwarantowaną dostawę i automatyczne odzyskiwanie skrętu > bez zwykłego ryzyka powielania wiadomości — idemponencja jest fundamentem > gwarancje dostawy są oparte na. ## Dokąd dalej - Środowisko uruchomieniowe, które napędza turę: [Bramka i silnik obrotowy](/pl/v1.0/architecture/gateway-turn-engine). - Jak odpowiedzi są zwracane dokładnie raz: [Niezawodna dostawa i odzyskiwanie](/pl/v1.0/architecture/delivery-outbox).