- Shipped
- 3 de agosto de 2026 a las 10:26 UTC
- Author
- kamo
- Commit
- ef17e2f
checkAccess resuelve al inquilino mirando hacia arriba.org:domain:.hostname, y estaba siendo entregado solicitud.nextUrl.hostname que detrás de Traefik es 127.0.0.1. Eso clave nunca existe, por lo que cada petición tomó la rama de "sin contexto de org para el nombre de host" y estaba permitido. El control de la permitida/negada y bloqueo de la temperatura nunca ha aplicado a cualquier cosa. Segura para corregir en lugar de diferir: una auditoría de los Redis en vivo encontró cero Acceso:rules:* y cero .org:domain:* teclas:* teclas, por lo que ningún inquilino tiene reglas configuradas y no existe una asignación de dominios. El comportamiento es de byte-idálica hoy en día. todavía toma la misma rama y el control se hace correcto para cuando las reglas primero están configurados, en lugar de nunca aplicar silenciosamente. (La propia auditoría necesitaba cuidado: redis-cli no está en el nodo, por lo que un escaneo anterior devolvió ceros que significaba "mando no encontrado" en lugar de "no llaves". Volver a correr dentro de la vaina de redis, donde AVA:v1:* correctamente mostró los 2 avatares en caché.) La derivación de la hostia está ahora en un solo lugar, requestHost(), compartida con la política de imagen. Esos dos lo habían derivado por separado y se equivocaron de dos maneras diferentes. La política de imagen tomó las dos últimas etiquetas de "127.0.0.1" y emitió un CSP permitiendo "tema.0.0", que bloqueó las imágenes de cada inquilino durante horas.