Risolvere l'org dal vero host richiesta, non l'indirizzo interno

Fixkamo-internal
Spegnimento
3 agosto 2026 alle ore 10:26 UTC
Autore
kamo
Impegno
ef17e2f

checkAccess risolve l'inquilino cercando `org:domain: <hostname>`, ed era essere consegnato request.nextUrl.hostname — che dietro Traefik è 127.0.0.1. Che cosa? chiave non esiste mai, quindi ogni richiesta ha preso il "nessun contesto org per il ramo hostname" ed era permesso. Il controllo IP consente/deny e temp-block non ha quindi mai applicato a qualsiasi cosa. Sicuro di correggere piuttosto che differire: un audit del live Redis trovato zero `access:rules:*` e zero `org:domain:*` tasti, quindi nessun inquilino ha regole configurate e nessuna mappatura di dominio esiste. Il comportamento è oggi byte-identico — ogni richiesta ancora prende lo stesso ramo — e il controllo diventa corretto per ogni volta che le regole sono configurati per la prima volta, invece di silenziosamente non applicare mai. (L'audit stesso necessario care: redis-cli non è sul nodo, quindi una scansione precedente ha restituito zero che significava "comand not found" piuttosto che "nessuna chiave". Ricorrere all'interno del redis pod, dove AVA:v1:* correttamente mostrato i 2 avatar cache.) La derivazione host è ora in un unico luogo, requestHost(), condivisa con la politica dell'immagine. Quei due l'avevano derivato separatamente e l'hanno sbagliato in due modi diversi — il la politica dell'immagine ha preso le ultime due etichette di "127.0.0.1" e ha emesso un CSP permettendo "theme.0.0", che ha bloccato le immagini di ogni inquilino per ore.

Tutte le modifiche

Come quello che vedi la spedizione?

Ognuno di questi aggiornamenti atterra automaticamente nello spazio di lavoro. Inizia gratis e guardalo crescere settimana dopo settimana.

Inizia gratis per sempreVisualizza il prezzo