@lamalibre/create-lamaste 4.4.1 → 4.6.0

package/vendor/docs/03-architecture/nginx-configuration.md

@@ -100,6 +100,9 @@ server {
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
+
+        # A relay assertion comes only from Gatekeeper, on a plugin's user surface
+        proxy_set_header X-Lamalibre-Relay-Assertion "";
     }
 
     # API paths with WebSocket upgrade support
@@ -118,6 +121,9 @@ server {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
 
+        # A relay assertion comes only from Gatekeeper, on a plugin's user surface
+        proxy_set_header X-Lamalibre-Relay-Assertion "";
+
         # WebSocket: only upgrade when client requests it
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection $connection_upgrade;
@@ -132,6 +138,7 @@ Key characteristics:
 - Includes the mTLS snippet for client certificate enforcement
 - Error pages 495 (no cert) and 496 (bad cert) serve a static help page with import instructions
 - Two `location` blocks: `/` for standard HTTP proxy, `/api` for WebSocket-capable proxy
+- Every location that proxies to the panel clears a client's `X-Lamalibre-Relay-Assertion` (`proxy_set_header X-Lamalibre-Relay-Assertion "";`): only Gatekeeper's, on a plugin's user surface, may reach the panel. The panel cannot write this vhost; `create-lamaste`'s redeploy refreshes it when its text differs (from 4.5)
 
 ### 2. Domain Panel Vhost (`lamalibre-lamaste-panel-domain`)
 
@@ -304,6 +311,9 @@ All three also declare the same request headers inside their `location /` (`TUNN
         proxy_set_header X-SSL-Client-DN "";
         proxy_set_header X-SSL-Client-Serial "";
 
+        # Never Authelia's session cookie: the browser's other cookies only
+        proxy_set_header Cookie $lamaste_backend_cookie;
+
         # WebSocket support
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
@@ -311,8 +321,9 @@ All three also declare the same request headers inside their `location /` (`TUNN
 
 - **Per location, not per server.** nginx inherits `proxy_set_header` from the enclosing level only when a level declares none of its own. Every tunnel location declares some (`Upgrade`, `Remote-*`), so headers placed at server level never reached the app — it saw `Host: 127.0.0.1:<port>` and no client address. Declared in the location, `Host`, `X-Real-IP`, `X-Forwarded-For` and `X-Forwarded-Proto` now reach the app.
 - **Client-certificate headers are always cleared.** The panel treats `X-SSL-Client-*` from nginx as proof of an mTLS client certificate. A tunnel vhost never passes client-supplied values through, whatever listens on its port.
+- **Authelia's session cookie never reaches the backend.** `Cookie` is set from `$lamaste_backend_cookie`: the browser's cookies with every `authelia_session` pair removed — or no `Cookie` header at all when nothing else is left, or when the map could not strip it ([The backend cookie map](#the-backend-cookie-map)). The cookie is scoped to the base domain, so the browser sends it to every tunnel host; an application that received it could replay the visitor's session on every authenticated host and every plugin's user surface. The agent-panel vhost's `location /` sets it the same way.
 - **Identity headers.** Public vhosts also clear `Remote-User`, `Remote-Groups`, `Remote-Name` and `Remote-Email` — a public tunnel has no authenticated user, and an app might trust those headers from an authenticated vhost. Authenticated and restricted vhosts set them from the Gatekeeper's answer, which replaces anything the client sent.
-- **Relay assertions on plugin tunnels.** A plugin tunnel (a vhost with a `pathPrefix`) ends at the agent's lamaste-agentd, which takes the user only from a relay assertion — its port can be reached without nginx, so a `Remote-User` header proves nothing to it. Authenticated and restricted plugin vhosts forward the one Gatekeeper signs for the request (`auth_request_set $relay_assertion $upstream_http_x_lamalibre_relay_assertion;` and `proxy_set_header X-Lamalibre-Relay-Assertion $relay_assertion;`); public plugin vhosts clear the header. App tunnel vhosts are unchanged. See [Security Model](../01-concepts/security-model.md#5c-the-agent-daemon-lamaste-agentd-and-relay-assertions).
+- **Relay assertions on plugin tunnels.** A plugin tunnel (a vhost with a `pathPrefix`) ends at the agent's lamaste-agentd, which takes the user only from a relay assertion — its port can be reached without nginx, so a `Remote-User` header proves nothing to it. Authenticated and restricted plugin vhosts forward the one Gatekeeper signs for the request (`auth_request_set $relay_assertion $upstream_http_x_lamalibre_relay_assertion;` and `proxy_set_header X-Lamalibre-Relay-Assertion $relay_assertion;`); public plugin vhosts clear the header. App tunnel vhosts clear it too: Gatekeeper signs one only for a plugin tunnel or the panel, never one a client sent. An app tunnel's backend gets the user only as the unsigned `Remote-*` headers — trustworthy as far as nginx goes, but anything that reaches its loopback port can send them as well. An app tunnel bound as a plugin's user surface also carries the [user-surface locations](#user-surface-locations). See [Security Model](../01-concepts/security-model.md#5c-the-agent-daemon-lamaste-agentd-and-relay-assertions).
 
 A tunnel created before `maxBodySizeMb` existed has no value and its vhost has no directive, so nginx applies its built-in 1 MiB limit until a body limit is set on it (`PATCH /api/tunnels/:id` with `maxBodySizeMb`, or **Edit** in the panel). Changing the access mode or body limit re-renders the vhost in place through the write-with-rollback pattern below; a disabled tunnel's vhost stays disabled.
 
@@ -341,6 +352,8 @@ location / {
     proxy_pass http://127.0.0.1:<port>;
     proxy_set_header X-Lamalibre-Relay-Assertion $relay_assertion;
     # X-SSL-Client-* are still sent for agents older than 4.3; lamaste-agentd 4.3 removes them unread
+    # Never Authelia's session cookie
+    proxy_set_header Cookie $lamaste_backend_cookie;
     # ...
 }
 ```
@@ -397,6 +410,64 @@ Optional Authelia protection is controlled by the `autheliaProtected` flag on th
 
 A custom-domain site may list `aliases` (e.g. `www.myblog.net`). They are served by a second server block that answers with a 301 to the primary host. One certificate lineage, named after the site's domain (`certbot certonly --nginx --cert-name <fqdn> -d <fqdn> -d <alias> ...`), covers the primary name and every alias, so both blocks point at the same `live/<fqdn>/` directory.
 
+### Web-surface vhosts
+
+A site a plugin owns for its [web surface](../04-api-reference/agent-hosted-plugins.md#web-surface) has a vhost of its own kind under the site name (`lamalibre-lamaste-site-<id>`), rendered by the panel from the plugin's state (`renderWebSurfaceVhost`) — never by the static-site generator. While the surface is served:
+
+```nginx
+server {
+    listen 443 ssl;
+    server_name piyasa.example.com;
+    ssl_certificate /etc/letsencrypt/live/piyasa.example.com/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/piyasa.example.com/privkey.pem;
+
+    root /var/www/lamaste/apps/market-indicators/current;
+    index index.html;
+
+    # Every path of the shell: Gatekeeper first (the API's locations ask on their own)
+    auth_request /internal/lamaste/shell-authz;
+    error_page 401 =302 https://auth.example.com/?rd=https://piyasa.example.com$request_uri;
+    error_page 403 = /internal/lamaste/shell-authz;
+
+    location = /internal/lamaste/shell-authz {
+        internal;
+        auth_request off;
+        proxy_pass http://127.0.0.1:9294/authz/user-surface-shell/piyasa.example.com;
+        # ... as every Gatekeeper subrequest
+    }
+
+    # /internal/lamaste/user-surface-authz, -401 and the /api/market-indicators/app
+    # locations — exactly the user-surface locations of a bound tunnel
+
+    # A script, style, font or image the current tree lacks: the previous
+    # tree's (a page still running the old shell), else 404
+    location ~* [.](?:js|mjs|css|woff2?|ttf|otf|png|jpe?g|gif|webp|avif|ico)$ {
+        if ($request_method !~ ^(GET|HEAD)$) { return 405; }
+        if ($http_service_worker) { return 404; }
+        add_header Content-Security-Policy "default-src 'self'; script-src 'self'; ..." always;
+        # X-Content-Type-Options, X-Frame-Options DENY, Referrer-Policy, COOP, CORP, Cache-Control no-cache
+        types { text/javascript js mjs; text/css css; ... }   # core WEB_TREE_CONTENT_TYPES
+        try_files $uri @previous;
+    }
+
+    # Everything else: the current tree's file, else the shell
+    location / {
+        # the same method check, worker refusal, headers and types
+        try_files $uri /index.html;
+    }
+
+    location @previous {
+        # the same headers and types
+        root /var/www/lamaste/apps/market-indicators/previous;
+        try_files $uri =404;
+    }
+}
+```
+
+`auth_request` sits at server level so every location of the shell asks Gatekeeper — the API's locations name their own subrequest, and the internal ones turn it `off`. The API's prefix location is `^~`, so the subresource regex never takes an API path. The shell's headers are set in its locations only: the API's answers are the panel's to head. A document, an SVG or a manifest is never served from the previous tree, and a service worker's script (`Service-Worker: script`) is always `404` — a worker would outlive the tree that installed it. The `types` block names each extension's content type from core's list (`lamaste-priv` accepts a `types` block in a location — `media/type ext…` entries only, no `include`) rather than trust the host's `mime.types`, which differs between nginx versions. `current` and `previous` are links the panel switches with a rename (see [Serving the tree](../04-api-reference/agent-hosted-plugins.md#serving-the-tree)); nginx follows them per request. While the surface is not served, the vhost answers everything with `503` (`Cache-Control: no-store`, a worker's script `404`) — and, once the plugin is uninstalled, `Clear-Site-Data: "storage"`.
+
+Moving a bound tunnel's host to a web surface hands the hostname over in **one reload**: the tunnel's vhost is unlinked, the site's written and linked, `nginx -t` run, nginx reloaded once; the tunnel's file stays installed, unlinked, so the tunnel can be enabled again once the site is deleted. On a failed test both are put back.
+
 ### 7. Public Tunnel Vhost (`lamalibre-lamaste-app-<name>`, access mode: public)
 
 Created when a tunnel is configured with public access. Direct proxy with no authentication.
@@ -421,7 +492,8 @@ server {
         proxy_set_header Remote-Email "";
 
         # ... the tunnel proxy headers (section 5): Host, X-Real-IP,
-        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared, WebSocket
+        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared,
+        #     Cookie $lamaste_backend_cookie, WebSocket
 
         proxy_pass http://127.0.0.1:<port>;
         proxy_http_version 1.1;
@@ -485,7 +557,8 @@ server {
         proxy_set_header Remote-Email $email;
 
         # ... the tunnel proxy headers (section 5): Host, X-Real-IP,
-        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared, WebSocket
+        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared,
+        #     Cookie $lamaste_backend_cookie, WebSocket
 
         proxy_pass http://127.0.0.1:<port>;
         proxy_http_version 1.1;
@@ -502,7 +575,8 @@ Key characteristics:
 
 - `auth_request` targets the Gatekeeper at `127.0.0.1:9294/authz/tunnel/<fqdn>` instead of Authelia directly
 - The subrequest names the tunnel by the vhost's own hostname, written into the configuration — in its path, `X-Original-URL` and `Host` — never by the client's `Host` header (see [below](#authorization-subrequests-name-their-own-hostname))
-- The Gatekeeper validates the Authelia session cookie and returns 200 (authenticated) or 401 (unauthenticated)
+- The Gatekeeper validates the Authelia session cookie and returns 200 (authenticated) or 401 (unauthenticated) — the subrequest is the one place the browser's `Cookie` goes as it is (`$http_cookie`), and Gatekeeper sends Authelia the `authelia_session` pair alone; a request with two is a 401
+- The backend gets the browser's other cookies (`$lamaste_backend_cookie`), never the session
 - The upstream receives `Remote-*` headers only as set from the Gatekeeper's response; client-supplied values under those names are replaced
 - 401 redirects to the Authelia login portal
 
@@ -510,7 +584,7 @@ Key characteristics:
 
 ### 9. Restricted Tunnel Vhost (`lamalibre-lamaste-app-<name>`, access mode: restricted)
 
-Created when a tunnel requires both Authelia login and an explicit access grant. Only users with a matching grant in `access-grants.json` can access the tunnel.
+Created when a tunnel requires both Authelia login and an explicit access grant. Only users with a matching grant in Gatekeeper (`gatekeeper.db`) can access the tunnel.
 
 ```nginx
 server {
@@ -560,7 +634,8 @@ server {
         proxy_set_header Remote-Email $email;
 
         # ... the tunnel proxy headers (section 5): Host, X-Real-IP,
-        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared, WebSocket
+        #     X-Forwarded-For/Proto, X-SSL-Client-* cleared,
+        #     Cookie $lamaste_backend_cookie, WebSocket
 
         proxy_pass http://127.0.0.1:<port>;
         proxy_http_version 1.1;
@@ -582,6 +657,96 @@ Key differences from the authenticated vhost:
 - `error_page 403 = /internal/lamaste/authz` replays the request to the Gatekeeper internal location. The `=` prefix causes nginx to use the response body and status code from the Gatekeeper, which serves an inline HTML access-request page with pre-filled message templates
 - 401 (unauthenticated) still redirects to Authelia login as before
 
+### User-surface locations
+
+An `authenticated` or `restricted` app tunnel bound as the user surface of agent-hosted plugins ([Tunnels API](../04-api-reference/tunnels.md#user-surface-binding)) carries, for each plugin whose installed, approved version declares `identity` **and whose hosting agent is the agent carrying the tunnel**, two more locations — `= /api/<route>/app` and `/api/<route>/app/` — and two internal ones they share (`renderTunnelVhost` with `userSurface`, `userSurfaceLocations` in `nginx.js`). A bound route whose plugin does not declare identity yet, or is not hosted by the tunnel's agent (the tunnel moved or its agent revoked, the plugin hosted elsewhere or not at all), has no locations: its requests take `location /` down the tunnel. Moving the tunnel, revoking its agent and hosting or unhosting the plugin re-render the vhost. A public vhost never carries them (the generator refuses).
+
+```nginx
+    # The user surface of agent-hosted plugins on this host: Gatekeeper
+    # vouches for the session's user to the panel, for one request each.
+    location = /internal/lamaste/user-surface-authz {
+        internal;
+
+        proxy_pass http://127.0.0.1:9294/authz/user-surface/app.example.com;
+        proxy_pass_request_body off;
+
+        proxy_set_header Content-Length "";
+        proxy_set_header Connection "";
+        proxy_set_header X-Original-Method $request_method;
+        proxy_set_header X-Original-URL https://app.example.com$request_uri;
+        proxy_set_header X-Forwarded-For $remote_addr;
+        # ... X-Forwarded-Host, -Proto, -Uri and -Method cleared ("")
+        proxy_set_header Host app.example.com;
+        proxy_set_header Cookie $http_cookie;
+
+        proxy_http_version 1.1;
+    }
+
+    location = /internal/lamaste/user-surface-401 {
+        internal;
+
+        proxy_pass http://127.0.0.1:9294/authz/user-surface-unauthenticated;
+        proxy_pass_request_body off;
+
+        proxy_set_header Content-Length "";
+        proxy_set_header Cookie "";
+        proxy_set_header Authorization "";
+        # Gatekeeper's rate limit counts the client nginx saw, never one a client named
+        proxy_set_header X-Forwarded-For $remote_addr;
+
+        proxy_http_version 1.1;
+    }
+
+    # The user surface of plugin "market-indicators"
+    location = /api/market-indicators/app { ... }   # the same block as below
+
+    location ^~ /api/market-indicators/app/ {
+        auth_request /internal/lamaste/user-surface-authz;
+        auth_request_set $relay_assertion $upstream_http_x_lamalibre_relay_assertion;
+
+        # The user, vouched for by Gatekeeper to the panel for this one request
+        proxy_set_header X-Lamalibre-Relay-Assertion $relay_assertion;
+
+        # Nothing else that any part of the panel trusts
+        proxy_set_header Cookie "";
+        proxy_set_header Authorization "";
+        proxy_set_header Remote-User "";
+        proxy_set_header Remote-Groups "";
+        proxy_set_header Remote-Name "";
+        proxy_set_header Remote-Email "";
+        proxy_set_header X-SSL-Client-Verify "";
+        proxy_set_header X-SSL-Client-DN "";
+        proxy_set_header X-SSL-Client-Serial "";
+        proxy_set_header X-Forwarded-Host "";
+
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $remote_addr;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header Connection "";
+
+        # No URI: the request target reaches the panel as the browser sent it
+        proxy_pass http://127.0.0.1:3100;
+        proxy_http_version 1.1;
+
+        client_max_body_size 10m;      # the plugin's internal tunnel's maxBodySizeMb
+        # No response lives longer (the panel ends one then)
+        proxy_read_timeout 3600s;
+        proxy_send_timeout 3600s;
+
+        # No session: a JSON 401, never a redirect
+        error_page 401 = /internal/lamaste/user-surface-401;
+    }
+```
+
+- **Gatekeeper attests, the panel identifies.** The subrequest names the tunnel as the tunnel's own does; Gatekeeper answers with a single-use relay assertion for the panel (never cached) and no `Remote-*` headers. The location passes that assertion to the panel and **nothing else of the browser's credentials**: the panel serves other contexts on the same listener, so everything any of them trusts — the client-certificate headers, `Remote-*`, a desktop session's `Authorization`, an administrator's 2FA `Cookie`, `X-Forwarded-Host` — is cleared. `X-Forwarded-For` is the client's address alone: the panel trusts one loopback hop, and the user surface's rate limit keys on it.
+- **`proxy_pass` names no URI**, so the panel receives `$request_uri` unchanged — the raw target the assertion is bound to and the panel compares byte for byte. A normalized path would differ from what Gatekeeper signed.
+- **The body limit is the plugin's** (its internal tunnel's `maxBodySizeMb`), not the tunnel's. The timeouts are one hour (`USER_SURFACE_MAX_RESPONSE_SECONDS`), the longest a user-surface response lives: long enough for server-sent events, which the panel streams unbuffered, and no longer than the panel lets any response stay open — it ends one after an hour, and at once when its user loses access.
+- **The panel's answer steers nothing.** It never carries `X-Accel-*` from an agent half (nginx obeys `X-Accel-Redirect` from 3100); the panel sets `X-Accel-Buffering: no` itself on an event stream. Every answer carries `Cross-Origin-Resource-Policy: same-origin`, `X-Content-Type-Options: nosniff` and `Content-Security-Policy: sandbox; default-src 'none'`, and no `Access-Control-*`.
+- **`= /api/<route>/app`** and **`/api/<route>/app/`** are both needed: a prefix location `/api/<route>/app` would also match `/api/<route>/apps`, which belongs to the tunnel.
+
+**A client's relay assertion is cleared wherever a browser reaches the panel.** The panel accepts `X-Lamalibre-Relay-Assertion` only on the user surface, and only from Gatekeeper; every location of the domain panel vhost, the auth vhost's panel locations, the agent-panel vhost's subrequest to the panel and the IP panel vhost set it to `""`, and so does every tunnel vhost that does not set Gatekeeper's (app tunnels, public vhosts). The panel's startup reconcile rewrites the domain panel and auth vhosts and every tunnel vhost; the IP panel vhost, which the installer writes and the panel cannot, is refreshed by `create-lamaste`'s redeploy (`Refreshing the IP panel vhost`).
+
 ### Authorization subrequests name their own hostname
 
 Every authorization subrequest — to Gatekeeper from an `authenticated` or `restricted` tunnel vhost (app and plugin tunnels), to Authelia from a protected static site and from the auth portal's `/api/user-access/authorize` — names the vhost by its own hostname, written into the configuration: `X-Original-URL https://<fqdn>$request_uri`; for Gatekeeper also the path, `/authz/tunnel/<fqdn>`, and `Host <fqdn>`. A tunnel's 401 login redirect returns to `https://<fqdn>$request_uri`. The client's `X-Forwarded-Host`, `-Proto`, `-Uri` and `-Method` are cleared in these subrequests. Generated vhosts contain no `$http_host`.
@@ -592,6 +757,37 @@ Gatekeeper authorizes the tunnel named in the path, and refuses a check whose `X
 
 Authelia evaluates the raw `$request_uri`, while nginx serves the normalized `$uri` (`/a/../b` is `/b`, `%2e` is `.`). Lamaste writes no path (`resources`) rules into Authelia's `access_control`, only hostname rules; a path rule added by hand would see a different path than nginx serves.
 
+## The backend cookie map
+
+Authelia's session cookie (`authelia_session`, the name core configures in `server/authelia.ts` and exports as `AUTHELIA_SESSION_COOKIE`) is scoped to the base domain, so a browser sends it to every host under it. No tunnel or agent backend may receive it: every location that proxies to one sends
+
+```nginx
+        proxy_set_header Cookie $lamaste_backend_cookie;
+```
+
+and the variable comes from an http-level map that create-lamaste installs as `/etc/nginx/conf.d/lamalibre-lamaste-backend-cookie.conf` (root-owned, 0644; nginx's own `nginx.conf` includes `conf.d/*.conf` in `http {}`). Its text is core's `renderBackendCookieMap()`:
+
+```nginx
+map $http_cookie $lamaste_cookie_strip_1 {
+    default $http_cookie;
+    "~^[ \t]*authelia_session[ \t]*=[^;]*(?:;[ \t]*)?(.*)$" $1;      # the first pair
+    "~^(.*?)[ \t]*;[ \t]*authelia_session[ \t]*=[^;]*(.*)$" $1$2;    # a later pair
+}
+# ... $lamaste_cookie_strip_2 to _4 from the one before, alike
+
+map $lamaste_cookie_strip_4 $lamaste_backend_cookie {
+    default $lamaste_cookie_strip_4;
+    "~(?:^|;)[ \t]*authelia_session[ \t]*=" "";                       # one left: fail closed
+}
+```
+
+- **One pair per round, four rounds.** A pair is the session cookie when its name — spaces and tabs around it trimmed — is exactly `authelia_session` (case-sensitive, as cookie names are and as Authelia reads them); `authelia_session_x`, `xauthelia_session` and a value containing `authelia_session=` are other cookies and stay. A browser holds one cookie per name, domain and path, so more than four is a request no browser of Authelia's makes — and a fifth pair empties the variable: the backend gets **no `Cookie` header at all**, never the session. nginx sends no header whose value is empty.
+- **The rest of the cookies stay**, in order — an application keeps its own session and preferences.
+- **Several `Cookie` lines** (HTTP/1.1, or HTTP/2's split cookies) are one `$http_cookie` to nginx, joined with `; `, and `proxy_set_header Cookie` replaces all of them.
+- **Gatekeeper reads the same grammar** (core `autheliaSessionCookies`): it is the only party handed the browser's `Cookie` as it is (`proxy_set_header Cookie $http_cookie;` in the authorization subrequests), sends Authelia the one pair alone, and refuses a request with more than one.
+- **Order of installation.** A vhost that names the variable fails `nginx -t` without the map and is rolled back, so the map is installed before the panel writes its first tunnel vhost — on a fresh install with nginx's own configuration, on a redeploy as its first step, before the running panel is stopped (a relay whose nginx refuses the map keeps the version it runs). The panel's startup reconcile then rewrites every tunnel and agent-panel vhost to use it.
+- **Tested** by evaluating the rendered map's expressions as PCRE does (they use only constructs PCRE and JavaScript read alike) against cookie strings with the session first, in the middle, last, repeated, beside similar names and with any spacing, and — where an nginx binary is installed — by running nginx with the map and a backend that reports the `Cookie` it received (`packages/provisioners/server/test/backend-cookie.test.js`).
+
 ## nginx Cache Zone (`lamaste_authz`)
 
 The Gatekeeper authorization responses are cached by nginx to reduce subrequest overhead. The cache zone is defined in a shared snippet:
@@ -714,12 +910,12 @@ nginx's master process runs as root and opens the files a configuration names
 - its **name** is one the panel manages: `lamalibre-lamaste-panel-domain`, `-auth`, `-tunnel`, `-app-<subdomain>`, `-agent-panel-<label>` or `-site-<uuid>`. `lamalibre-lamaste-panel-ip` (written by the installer) may only be enabled or disabled — which is how panel 2FA turns the IP vhost off;
 - every **directive** is on the allow-list for its context, with arguments that cannot name a file outside what Lamaste serves:
 
-| Context    | Allowed                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
-| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| top level  | `server`, `map` (plain `key value;` entries, no `include`), `limit_req_zone`                                                                                                                                                                                                                                                                                                                                                                                 |
-| `server`   | `listen 443` / `[::]:443` with optional `ssl` / `http2`; `server_name` (hostnames); `ssl_certificate(_key)` only `/etc/letsencrypt/live/<name>/{fullchain,privkey}.pem`; `include` only `/etc/nginx/snippets/lamalibre-lamaste-*.conf`; `root` only under `/var/www/lamaste/`; `ssl_protocols`, `ssl_ciphers`, `ssl_prefer_server_ciphers`, `client_max_body_size`, `index`, `add_header`, `proxy_set_header`, `error_page`, `return`, `rewrite`, `location` |
-| `location` | `proxy_pass` only `http://127.0.0.1:<port>[/path]`; `root` / `alias` only under `/var/www/lamaste/`; `proxy_set_header`, `proxy_http_version`, `proxy_read_timeout`, `proxy_send_timeout`, `proxy_buffers`, `proxy_next_upstream`, `proxy_pass_request_body`, `auth_request`, `auth_request_set`, `limit_req`, `try_files`, `index`, `add_header`, `error_page`, `client_max_body_size`, `internal`, `return`, `rewrite`, `if`, nested `location`            |
-| `if`       | `return`, `rewrite`                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| Context    | Allowed                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| top level  | `server`, `map` (plain `key value;` entries, no `include`), `limit_req_zone`                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| `server`   | `listen 443` / `[::]:443` with optional `ssl` / `http2`; `server_name` (hostnames); `ssl_certificate(_key)` only `/etc/letsencrypt/live/<name>/{fullchain,privkey}.pem`; `include` only `/etc/nginx/snippets/lamalibre-lamaste-*.conf`; `root` only under `/var/www/lamaste/`; `auth_request` only a URI of the server or `off`; `ssl_protocols`, `ssl_ciphers`, `ssl_prefer_server_ciphers`, `client_max_body_size`, `index`, `add_header`, `proxy_set_header`, `error_page`, `return`, `rewrite`, `location` (a path, or a named location `@name`) |
+| `location` | `proxy_pass` only `http://127.0.0.1:<port>[/path]`; `root` / `alias` only under `/var/www/lamaste/`; `proxy_set_header`, `proxy_http_version`, `proxy_read_timeout`, `proxy_send_timeout`, `proxy_buffers`, `proxy_next_upstream`, `proxy_pass_request_body`, `auth_request`, `auth_request_set`, `limit_req`, `try_files` (the last argument may name a location, `@name`), `index`, `add_header`, `error_page`, `client_max_body_size`, `internal`, `return`, `rewrite`, `if`, nested `location`                                                   |
+| `if`       | `return`, `rewrite`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 
 Port 80 is not allowed: it belongs to the installer's HTTPS redirect and to certbot's HTTP-01 challenges. Backslashes, `${`, control characters and non-ASCII text outside comments are refused rather than interpreted, as is any directive not listed — including ones nginx would accept (`access_log`, `log_format`, `ssl_*` files elsewhere, `proxy_pass` to another host, ...). A refused `write` fails with `nginx site write failed for <name>: lamaste-priv: vhost line <n>: ...` and leaves the previous vhost in place.
 
@@ -782,6 +978,8 @@ The 24-hour timeout (`proxy_read_timeout 86400s`) is set on tunnel and app vhost
 ```
 /etc/nginx/
 ├── nginx.conf                          ← Default nginx config (not modified by Lamaste)
+├── conf.d/
+│   └── lamalibre-lamaste-backend-cookie.conf  ← http-level map: $lamaste_backend_cookie (installer, redeploy)
 ├── sites-available/
 │   ├── lamalibre-lamaste-http-redirect         ← :80 catch-all → HTTPS (created by installer)
 │   ├── lamalibre-lamaste-panel-ip              ← IP:9292 panel access (created by installer)
@@ -814,6 +1012,8 @@ All Lamaste-managed files are prefixed with `lamalibre-lamaste-` to distinguish
 | `lamalibre-lamaste-panel-ip`      | Installation           | Never (fallback access) |
 | `lamalibre-lamaste-http-redirect` | Installation, redeploy | Uninstall               |
 
+Beside them the installer writes the http-level map `conf.d/lamalibre-lamaste-backend-cookie.conf` — on a fresh install with nginx's configuration, on every redeploy as the first step ([The backend cookie map](#the-backend-cookie-map)); `lamaste-server uninstall` removes it after the sites that use it.
+
 `lamalibre-lamaste-http-redirect` is the port-80 catch-all:
 
 ```nginx
@@ -848,8 +1048,8 @@ Without it nothing listens on port 80 and `http://` links to the relay's hostnam
 
 A vhost is written when its tunnel or site is created or changed, so a generator change does not reach existing vhosts by itself. At startup, once onboarding is complete, the panel (`lib/vhost-reconcile.js`) renders installed vhosts again and rewrites each one whose text differs through the write-with-rollback pattern, on the certificate directory the installed file names (a wildcard certificate stays a wildcard certificate). A rewrite never links a vhost that is not linked now; a disabled tunnel's vhost is unlinked:
 
-- **Before it listens:** the auth portal (`lamalibre-lamaste-auth`) and every static site, from `sites.json` and the domain. Site changes take no lock, so this runs while none can arrive.
-- **Once it listens**, under the tunnel lock: every agent-panel, app and plugin tunnel, from `tunnels.json` — the stored access mode (`restricted` when absent, as Gatekeeper reads it), the plugin route, and the body limit only when the tunnel has one. After listen because a rewritten agent-panel vhost asks the panel about every request.
+- **Before it listens:** the domain panel vhost (`lamalibre-lamaste-panel-domain`), the auth portal (`lamalibre-lamaste-auth`) and every static site, from `sites.json` and the domain. Site changes take no lock, so this runs while none can arrive.
+- **Once it listens**, under the tunnel lock: every agent-panel, app and plugin tunnel, from `tunnels.json` — the stored access mode (`restricted` when absent, as Gatekeeper reads it), the plugin route, the body limit only when the tunnel has one, and the user-surface locations of the bound routes it serves now. The same reconcile, limited to the tunnels a route is bound to, runs whenever whether that route is served can change: the plugin's approval, update or revert, hosting and unhosting, uninstall. After listen because a rewritten agent-panel vhost asks the panel about every request.
 
 That is how vhosts written before 4.3 start forwarding relay assertions (agent-panel and plugin tunnels) and start naming their own hostname to Gatekeeper and Authelia (see [above](#authorization-subrequests-name-their-own-hostname)). A rewrite never adds or removes authentication: a tunnel or site vhost whose `auth_request` disagrees with its state (a public vhost for a restricted tunnel, say) is logged and left alone until the tunnel or site is reconfigured — the agent-panel vhost, which gains the panel's `auth_request` beside its mTLS check, is the exception. Missing vhosts are logged (a site still waiting for its certificate has none yet); a failed rewrite restores the previous file and the others still run.
 
@@ -857,16 +1057,19 @@ A tunnel vhost left as it was fails closed: Gatekeeper refuses its `/authz/check
 
 ## Key Files
 
-| File                                                     | Role                                                                                              |
-| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
-| `packages/provisioners/server/src/tasks/nginx.js`        | Installer: self-signed cert, mTLS snippet, IP vhost, port-80 redirect                             |
-| `packages/provisioners/server/src/lib/http-redirect.js`  | Installs/refreshes the port-80 redirect site (installer and redeploy)                             |
-| `packages/server/daemon/src/lib/nginx.js`                | Runtime: vhost generation, write-with-rollback, enable/disable/reload                             |
-| `packages/provisioners/server/scripts/lamaste-priv`      | Root helper (`/usr/local/sbin/lamaste-priv`): site names, vhost allow-list, install/enable/remove |
-| `/etc/nginx/snippets/lamalibre-lamaste-mtls.conf`        | Shared mTLS snippet                                                                               |
-| `/etc/nginx/snippets/lamalibre-lamaste-authz-cache.conf` | Gatekeeper proxy_cache zone definition                                                            |
-| `/etc/nginx/sites-available/lamalibre-lamaste-*`         | Vhost configuration files                                                                         |
-| `/etc/nginx/sites-enabled/lamalibre-lamaste-*`           | Symlinks to enabled vhosts                                                                        |
+| File                                                      | Role                                                                                              |
+| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
+| `packages/provisioners/server/src/tasks/nginx.js`         | Installer: self-signed cert, mTLS snippet, IP vhost, port-80 redirect                             |
+| `packages/provisioners/server/src/lib/http-redirect.js`   | Installs/refreshes the port-80 redirect site (installer and redeploy)                             |
+| `packages/provisioners/server/src/lib/backend-cookie.js`  | Installs/refreshes the backend cookie map (installer and redeploy), `nginx -t` with rollback      |
+| `packages/core/lib/src/authelia-session.ts`               | The session cookie's name, the map's text (`renderBackendCookieMap`), Gatekeeper's reader         |
+| `/etc/nginx/conf.d/lamalibre-lamaste-backend-cookie.conf` | Defines `$lamaste_backend_cookie`: the browser's cookies without `authelia_session`               |
+| `packages/server/daemon/src/lib/nginx.js`                 | Runtime: vhost generation, write-with-rollback, enable/disable/reload                             |
+| `packages/provisioners/server/scripts/lamaste-priv`       | Root helper (`/usr/local/sbin/lamaste-priv`): site names, vhost allow-list, install/enable/remove |
+| `/etc/nginx/snippets/lamalibre-lamaste-mtls.conf`         | Shared mTLS snippet                                                                               |
+| `/etc/nginx/snippets/lamalibre-lamaste-authz-cache.conf`  | Gatekeeper proxy_cache zone definition                                                            |
+| `/etc/nginx/sites-available/lamalibre-lamaste-*`          | Vhost configuration files                                                                         |
+| `/etc/nginx/sites-enabled/lamalibre-lamaste-*`            | Symlinks to enabled vhosts                                                                        |
 
 ## Design Decisions
 
@@ -890,6 +1093,8 @@ nginx emits error 495 when no client certificate is provided and 496 when the ce
 
 Chisel tunnel connections and some app WebSocket connections are long-lived. nginx's default `proxy_read_timeout` of 60 seconds would close these connections, causing tunnel drops. The 24-hour timeout is effectively "never timeout" for practical purposes, while still allowing nginx to reclaim resources from genuinely dead connections.
 
+A plugin's user-surface locations are the exception: one hour, the longest the panel lets a user-surface response live. A response that outlived its user's access — an event stream left open after the user was disabled — is what the bound is there to stop; the panel also ends such a response within seconds of the change.
+
 ### Why a root helper for nginx operations?
 
 The Panel Server runs as the `lamaste` user, not root. Writing to `/etc/nginx/sites-available/` and reloading nginx require root privileges. Instead of running the Panel Server as root, Lamaste allows the `lamaste` user a few fixed command lines (`nginx -t`, `systemctl reload nginx`, ...) and the root-owned `lamaste-priv` helper, which accepts only the panel's own site names and only vhosts built from the allow-listed directives above. Earlier versions used sudoers rules with wildcards (`mv /tmp/nginx-* /etc/nginx/sites-available/*`); a sudoers `*` also matches spaces, so such a rule accepted extra arguments, and even an exact rule would have let the panel install any nginx configuration — which nginx's root master process would act on. Certbot is reached only through the root-owned `/usr/local/sbin/lamaste-certbot` wrapper, which validates hostnames and email and runs certbot with a fixed argument vector. See [Security Model](../01-concepts/security-model.md#privilege-boundary).

package/vendor/docs/03-architecture/overview.md

@@ -6,7 +6,7 @@
 
 Lamaste has three main pieces:
 
-1. **The Installer** (`npx @lamalibre/create-lamaste@4.4.1`) — a one-shot script you run once on a fresh VPS. It sets up nginx, generates security certificates, and deploys a web-based control panel. After it finishes, you never SSH into the server again.
+1. **The Installer** (`npx @lamalibre/create-lamaste@4.6.0`) — a one-shot script you run once on a fresh VPS. It sets up nginx, generates security certificates, and deploys a web-based control panel. After it finishes, you never SSH into the server again.
 
 2. **The Panel** (browser UI + backend API) — a management interface protected by a client certificate. Through it, you configure your domain, create tunnels, manage users, and monitor services.
 
@@ -185,28 +185,25 @@ End User → nginx :443 → auth_request → 127.0.0.1:9294/authz/tunnel/<fqdn>
                                     │  In-memory session  │
                                     │  cache (Map)        │
                                     │                     │
-                                    │  State files:       │
-                                    │  - groups.json      │
-                                    │  - access-grants.json│
+                                    │  State:             │
+                                    │  - gatekeeper.db    │
                                     │  - gatekeeper.json  │
                                     └─────────────────────┘
 ```
 
-**Grant model:** The Gatekeeper uses a generic principal-to-resource grant model. A principal is an Authelia user or a Lamaste group. A resource is a tunnel subdomain or other protected endpoint. Grants are stored in `/etc/lamalibre/lamaste/access-grants.json`.
+**Grant model:** The Gatekeeper uses a generic principal-to-resource grant model. A principal is an Authelia user or a Lamaste group. A resource is a tunnel subdomain or other protected endpoint. Grants are stored in Gatekeeper's SQLite database, `/etc/lamalibre/lamaste/gatekeeper.db`. A plugin grant whose `context` names `roles` is an agent-hosted plugin's entitlement (see [Agent-Hosted Plugins](../04-api-reference/agent-hosted-plugins.md#users-and-identity)).
 
-**Lamaste groups:** Separate from Authelia groups. Stored in `/etc/lamalibre/lamaste/groups.json`. Lamaste groups allow the admin to organize users for access control without modifying Authelia's `users.yml`.
+**Lamaste groups:** Separate from Authelia groups. Stored in `gatekeeper.db`. Lamaste groups allow the admin to organize users for access control without modifying Authelia's `users.yml`.
 
 **Two-layer caching:**
 
 1. **nginx `proxy_cache`** — the installer defines the `lamaste_authz` cache zone (1m keys, 10m storage) and a location-level policy (key `$server_name|$cookie_authelia_session`, `200` cached for 10 seconds, `403` never), but the generated vhosts do not include it today (see [nginx Configuration](nginx-configuration.md#nginx-cache-zone-lamaste_authz)).
 2. **In-memory session cache** — the Gatekeeper keeps validated Authelia sessions in a `Map` keyed by an HMAC of the session cookie, so a check within the TTL does not ask Authelia again. It caches the identity, not the decision: grants are checked on every request.
 
-**State files:** All stored in `/etc/lamalibre/lamaste/` with 0600 permissions, `lamaste:lamaste` ownership, and atomic writes (tmp, fsync, rename):
+**State:** In `/etc/lamalibre/lamaste/` with 0600 permissions and `lamaste:lamaste` ownership:
 
-- `groups.json` — Lamaste group definitions and membership
-- `access-grants.json` — Principal-to-resource access grants
-- `gatekeeper.json` — Settings (admin contact info, cache TTL, logging configuration)
-- `access-request-log.json` — Optional log of denied access attempts (for admin review)
+- `gatekeeper.db` — SQLite (WAL): Lamaste groups and members, access grants, the optional log of denied access attempts (for admin review); read on every check
+- `gatekeeper.json` — Settings (admin contact info, cache TTL, logging configuration), atomic writes (tmp, fsync, rename)
 
 **Service:** Runs as `lamalibre-lamaste-gatekeeper.service` (systemd), binding `127.0.0.1:9294`. nginx is the sole entry point — the Gatekeeper is never directly accessible from the internet.
 
@@ -321,7 +318,7 @@ lamaste/
 │   │           ├── files.js          ← Static site file operations (upload, delete, list)
 │   │           └── app-error.js      ← Operational error class (AppError)
 │   │
-│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.4.1)
+│   ├── lamaste-server-ui/          ← React 18 + Vite + Tailwind SPA + shared admin components (@lamalibre/lamaste-server-ui@4.6.0)
 │   │   └── src/
 │   │       ├── index.js              ← Package exports (pages, context, utilities)
 │   │       ├── context/
@@ -337,7 +334,7 @@ lamaste/
 │   │       │   └── formatters.js     ← Byte, uptime, relative time formatters
 │   │       └── pages/                ← Admin pages (Dashboard, Tunnels, Sites, Users, Certs, Services, Plugins, Tickets, Settings)
 │   │
-│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.4.1)
+│   ├── lamaste-agent-ui/          ← Shared React agent UI (pages, context, components) (@lamalibre/lamaste-agent-ui@4.6.0)
 │   │
 │   ├── lamaste-tickets/              ← Agent-to-agent authorization SDK (mTLS, undici)
 │   │   └── src/
@@ -377,7 +374,7 @@ lamaste/
 │           │   │   └── CompleteStep.jsx   ← Credentials + TOTP QR + next steps
 │           │   ├── management/            ← Legacy standalone implementations (kept for reference)
 │           │   │   ├── Certificates.jsx   ← Standalone certificates page (dead code)
-│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.4.1)
+│           │   │   ├── Dashboard.jsx      ← Standalone dashboard (not imported — App.jsx uses @lamalibre/lamaste-server-ui@4.6.0)
 │           │   │   ├── Plugins.jsx        ← Standalone plugins page (dead code)
 │           │   │   ├── Services.jsx       ← Standalone services page (dead code)
 │           │   │   ├── Settings.jsx       ← Standalone settings page (dead code)
@@ -486,7 +483,7 @@ The Panel Server runs as the `lamaste` user with minimal privileges and cannot b
 The full lifecycle of a Lamaste installation:
 
 ```
-Phase 1: Installation (npx @lamalibre/create-lamaste@4.4.1)
+Phase 1: Installation (npx @lamalibre/create-lamaste@4.6.0)
   └─ OS hardening, Node.js, mTLS certs, nginx, panel deploy
   └─ Result: Panel accessible at https://<ip>:9292
 
@@ -530,8 +527,7 @@ Phase 4: Recovery (if needed)
 | `/etc/systemd/system/authelia.service`                  | Authelia systemd unit                                   |
 | `/etc/lamalibre/lamaste/plugins.json`                   | Plugin registry (installed plugins and status)          |
 | `/etc/lamalibre/lamaste/plugins/`                       | Per-plugin data directories                             |
-| `/etc/lamalibre/lamaste/groups.json`                    | Lamaste group definitions and membership                |
-| `/etc/lamalibre/lamaste/access-grants.json`             | Generic access grants (principal → resource)            |
+| `/etc/lamalibre/lamaste/gatekeeper.db`                  | Gatekeeper: groups, access grants, denied-access log    |
 | `/etc/lamalibre/lamaste/gatekeeper.json`                | Gatekeeper settings (cache TTL, admin contact, logging) |
 | `/etc/lamalibre/lamaste/push-install-config.json`       | Push install configuration and policies                 |
 | `/etc/lamalibre/lamaste/push-install-sessions.json`     | Push install session audit log                          |

package/vendor/docs/03-architecture/panel-client.md

@@ -10,9 +10,9 @@ The client has two modes. On first visit, it shows an onboarding wizard that wal
 
 ## Shared Panel Packages
 
-The management-mode admin pages (Dashboard, Tunnels, Sites, Users, Certificates, Services, Plugins, Tickets, Logs, Settings) live in `@lamalibre/lamaste-server-ui@4.4.1`. This package provides both the browser SPA build and the shared admin components consumed by `lamaste-desktop` (Tauri app).
+The management-mode admin pages (Dashboard, Tunnels, Sites, Users, Certificates, Services, Plugins, Tickets, Logs, Settings) live in `@lamalibre/lamaste-server-ui@4.6.0`. This package provides both the browser SPA build and the shared admin components consumed by `lamaste-desktop` (Tauri app).
 
-The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are extracted into a separate shared package: `@lamalibre/lamaste-agent-ui@4.4.1`. This package is consumed by `lamaste-desktop` for agent mode.
+The agent-mode pages (Dashboard, Tunnels, Services, Plugins, Logs, Settings) are extracted into a separate shared package: `@lamalibre/lamaste-agent-ui@4.6.0`. This package is consumed by `lamaste-desktop` for agent mode.
 
 The shared package exposes an `AdminClientContext` abstraction that decouples admin UI pages from their data transport. Each host provides its own client implementation:
 
@@ -118,7 +118,7 @@ The shell renders the appropriate step component and shows a progress indicator
 
 ### Management Mode
 
-React Router handles navigation within the `Layout` component (sidebar + content area). Management page components are imported from the shared `@lamalibre/lamaste-server-ui@4.4.1` package and wrapped with the `AdminClientProvider` (which supplies the web-specific data client):
+React Router handles navigation within the `Layout` component (sidebar + content area). Management page components are imported from the shared `@lamalibre/lamaste-server-ui@4.6.0` package and wrapped with the `AdminClientProvider` (which supplies the web-specific data client):
 
 | Path                     | Component           | Description                                                         |
 | ------------------------ | ------------------- | ------------------------------------------------------------------- |
@@ -350,9 +350,9 @@ The app root wraps all content in five providers:
 ```
 
 1. **QueryClientProvider** — react-query cache with global defaults (`retry: 1`, `refetchOnWindowFocus: false`)
-2. **AdminClientProvider** — from `@lamalibre/lamaste-server-ui@4.4.1`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
-3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.4.1`, notification toast system
-4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.4.1`, handles 2FA verification prompts when the panel has 2FA enabled
+2. **AdminClientProvider** — from `@lamalibre/lamaste-server-ui@4.6.0`, supplies the host-specific data client (`webAdminClient` for browser fetch, Tauri `invoke` for desktop)
+3. **ToastProvider** — from `@lamalibre/lamaste-server-ui@4.6.0`, notification toast system
+4. **TwoFaProvider** — from `@lamalibre/lamaste-server-ui@4.6.0`, handles 2FA verification prompts when the panel has 2FA enabled
 5. **BrowserRouter** — React Router for client-side navigation
 
 ## Documentation Viewer

package/vendor/docs/03-architecture/panel-server.md

@@ -453,7 +453,7 @@ See [nginx-configuration.md](./nginx-configuration.md) for detailed coverage.
 
 ### chisel-users.js — Chisel Credentials and Grants
 
-- Thin shim over `@lamalibre/lamaste@4.4.1/server`: per-agent credentials in `chisel-credentials.json` (0600)
+- Thin shim over `@lamalibre/lamaste@4.6.0/server`: per-agent credentials in `chisel-credentials.json` (0600)
 - Renders the authfile `chisel-users` from the credentials and `tunnels.json`: each `agent-<label>` may bind exactly `^R:127\.0\.0\.1:<port>$` for its enabled tunnels
 - Adds the `lamaste-no-grants` sentinel user (password in `chisel-sentinel`, 0600) so the authfile is never empty — Chisel disables authentication on an empty authfile
 - Never grants a reserved port (3100, 9090, 9091, 9292, 9294) or a port claimed by two tunnels
@@ -495,6 +495,7 @@ If the authfile cannot be established, Chisel is **stopped and disabled** and th
 - Writes YAML configuration (bcrypt cost 12, file-based users, TOTP, session cookies) directly, without sudo: `/etc/authelia` is `lamaste:lamaste-authelia 2770` (setgid), files are written as a temp file + fsync + rename (`configuration.yml` 0640, `users.yml` 0660, `.secrets.json` 0600)
 - User CRUD: creates users with bcrypt-hashed passwords, reads/writes `users.yml`
 - Stores a user's TOTP secret with `sudo lamaste-priv authelia-totp <username>` (secret on stdin), which runs Authelia's CLI as `lamaste-authelia` — the database is that account's file
+- Deletes a removed user's second factors (`sudo lamaste-priv authelia-user purge-second-factors <username>`: TOTP configuration and WebAuthn credentials) and asks whether Authelia holds an OpenID Connect opaque identifier for a username (`… has-oidc-identifier <username>`, `yes`/`no`) before it gives the username to a new user — core `server/authelia-user-storage.ts`
 - TOTP generation: `crypto.randomBytes(20)` → base32-encoded secret → `otpauth://` URI (parameterized `generateTotpSecret(username, { issuer })` — reused by panel 2FA via `lib/totp.js`)
 - `base32Decode()` utility for decoding base32 TOTP secrets into raw bytes
 - Manages service lifecycle
@@ -535,7 +536,7 @@ Agent-to-agent authorization with scopes, instances, tickets, and sessions. Prov
 - **Periodic cleanup** — stale/dead instances, expired tickets, dead sessions
 - **Concurrency** — promise-chain mutex with atomic file writes (temp → fsync → rename)
 
-Client SDK: `@lamalibre/lamaste-tickets@4.4.1` (TypeScript, undici) provides `TicketClient`, `TicketInstanceManager` (source side), and `TicketSessionManager` (target side) for plugin integration.
+Client SDK: `@lamalibre/lamaste-tickets@4.6.0` (TypeScript, undici) provides `TicketClient`, `TicketInstanceManager` (source side), and `TicketSessionManager` (target side) for plugin integration.
 
 State files: `/etc/lamalibre/lamaste/ticket-scopes.json` (scopes, instances, assignments) and `/etc/lamalibre/lamaste/tickets.json` (tickets, sessions).