¿Cómo gestiona Immich la autenticación en sesiones locales y remotas?

Immich mantiene la identidad de la cuenta en el servidor, mientras que los clientes locales y remotos presentan las credenciales de sesión mediante rutas que pueden diferir en origen, proxy y redirecciones.

El usuario puede ser el mismo en la LAN y fuera de casa, pero el navegador, la aplicación móvil, el proxy inverso y el proveedor de identidad no gestionan todas las transiciones de la misma manera. Por ello, los fallos de autenticación deben rastrearse desde la emisión de las credenciales, pasando por el transporte, hasta la validación del servidor.

La identidad y las credenciales de sesión son capas diferentes

La autenticación demuestra primero una identidad; después, las solicitudes presentan el material de sesión que valida el servidor. Una contraseña correcta o un resultado válido del proveedor de identidad puede coexistir con un fallo de sesión posterior si falta un token, ha caducado, se ha almacenado bajo otro origen o se envía mediante una ruta que el servidor interpreta de forma diferente.

Una guía independiente para configurar Authelia OIDC en Immich muestra cómo participa un proveedor de identidad externo en el inicio de sesión, mientras Immich sigue siendo la aplicación de destino. Esto aclara el límite: el proveedor establece la identidad mediante redirecciones, pero Immich continúa asignando el resultado a su propio usuario y gestionando su propia sesión.

Al depurar, registra si el fallo ocurre antes de aceptar las credenciales, durante la devolución de la redirección o en una solicitud posterior a la API. Cada punto implica componentes diferentes. Restablecer repetidamente las contraseñas no puede solucionar una discrepancia en la URL de devolución, del mismo modo que modificar el proxy no puede reparar una cuenta de Immich deshabilitada.

Las URL locales y remotas crean contextos de cliente diferentes

Una dirección local y un nombre de host público pueden llegar al mismo contenedor de Immich, pero los clientes ven esquemas, hosts, certificados, respuestas DNS y saltos de proxy diferentes. Los navegadores separan el almacenamiento por origen, mientras que los clientes nativos pueden aplicar sus propias reglas de redirección y certificados. La continuidad de la sesión no atraviesa automáticamente esos límites.

Un caso de la comunidad de Caddy informa de que Authelia funciona con Immich en un navegador web, mientras que la aplicación móvil produce errores. Se trata de un diseño de proxy concreto, pero demuestra el punto general: una autenticación correcta en el navegador no valida el flujo de redirección y API de un cliente nativo.

Prueba explícitamente cada combinación compatible: navegador en la LAN, navegador remoto, móvil en la LAN y móvil remoto. Registra la URL exacta y el paso en el que ocurre el fallo. Si solo falla un contexto, compara su cadena de certificados, URI de redirección, gestión de cookies o tokens y ruta DNS antes de cambiar los permisos de usuarios compartidos.

El proxy debe conservar el contexto de la solicitud

Un proxy inverso termina o reenvía el transporte antes de que las solicitudes lleguen a Immich. La aplicación puede depender del esquema, el host y la información del cliente reenviados para generar enlaces o evaluar el contexto de la solicitud. Una traducción incorrecta puede hacer que las devoluciones apunten al origen equivocado o que una sesión válida parezca incoherente.

El artículo de ZimaSpace sobre la ruta de datos de Immich destaca que el comportamiento visible de la aplicación atraviesa varias dependencias, no solo el límite de un contenedor. La autenticación sigue el mismo razonamiento: DNS, terminación TLS, enrutamiento del proxy, la aplicación y cualquier proveedor de identidad participan antes de que una solicitud autenticada de contenido multimedia tenga éxito.

Inspecciona el registro de red del navegador o los registros del proxy móvil desde el inicio de sesión inicial hasta una solicitud autenticada a la API. Confirma que el esquema y el host visibles externamente se mantengan coherentes en las redirecciones. Después, verifica que la aplicación reciba la información de reenvío prevista. Cambia un ajuste del proxy cada vez y conserva una ruta LAN conocida que funcione.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica la continuidad de la sesión con una matriz de rutas

Crea filas para el navegador y el móvil, y columnas para el acceso LAN y remoto. En cada celda, prueba un inicio de sesión nuevo, la recarga de la página o de la cronología, el reinicio de la aplicación, la renovación del token después de que transcurra cierto tiempo, el cierre de sesión y el acceso a un recurso perteneciente a otra cuenta de prueba. Nunca uses fotos exclusivas de producción para probar permisos.

Una guía de acceso remoto seguro para Immich aborda la tunelización HTTPS, la conectividad remota, la supervisión y la resolución de problemas. Su valor arquitectónico reside en que la disponibilidad remota añade una capa de acceso alrededor de la aplicación; esa capa debe probarse sin asumir que modifica la propiedad subyacente de los usuarios ni el modelo de autorización de Immich.

Clasifica los fallos según el primer paso que se rompe: accesibilidad, TLS, redirección, aceptación de credenciales, persistencia de la sesión o autorización del recurso. La matriz solo está completa cuando se observan tanto los casos de éxito como las denegaciones previstas. Una sesión que permanece iniciada pero expone los recursos del usuario equivocado no constituye un éxito de autenticación.