Como gere o Immich a autenticação entre sessões locais e remotas?

O Immich mantém a identidade da conta no servidor, enquanto os clientes locais e remotos apresentam credenciais de sessão através de caminhos que podem diferir na origem, no proxy e nos redirecionamentos.

O utilizador pode ser o mesmo na LAN e fora de casa, mas o navegador, a aplicação móvel, o proxy inverso e o fornecedor de identidade não tratam todas as transições da mesma forma. Por isso, as falhas de autenticação devem ser rastreadas desde a emissão das credenciais, passando pelo transporte, até à validação no servidor.

A identidade e as credenciais de sessão são camadas diferentes

A autenticação começa por provar uma identidade; depois, os pedidos subsequentes apresentam material de sessão que o servidor valida. Uma palavra-passe correta ou um resultado correto do fornecedor de identidade pode coexistir com uma falha de sessão posterior se faltar um token, se este tiver expirado, estiver armazenado noutra origem ou for enviado através de um caminho que o servidor interprete de forma diferente.

Um guia independente sobre a configuração do Authelia OIDC para o Immich mostra um fornecedor de identidade externo a participar no início de sessão, enquanto o Immich continua a ser a aplicação de destino. Isto clarifica a fronteira: o fornecedor estabelece a identidade através de redirecionamentos, mas o Immich continua a associar o resultado ao seu próprio utilizador e ao comportamento da sua sessão.

Ao diagnosticar problemas, registe se a falha ocorre antes de as credenciais serem aceites, durante o retorno do redirecionamento ou num pedido posterior à API. Esses pontos envolvem componentes diferentes. Repor repetidamente as palavras-passe não corrige uma incompatibilidade no URL de retorno, e alterações no proxy não reativam uma conta Immich desativada.

Os URLs locais e remotos criam contextos de cliente diferentes

Um endereço local e um nome de anfitrião público podem chegar ao mesmo contentor Immich, mas os clientes veem esquemas, anfitriões, certificados, respostas DNS e saltos de proxy diferentes. Os navegadores particionam o armazenamento por origem, enquanto os clientes nativos podem aplicar as suas próprias regras de redirecionamento e certificados. A continuidade da sessão não atravessa automaticamente essas fronteiras.

Um caso na comunidade do Caddy relata que o Authelia funciona com o Immich num navegador, enquanto a aplicação móvel produz erros. Trata-se de uma configuração de proxy específica, mas demonstra o ponto mais amplo: uma autenticação bem-sucedida no navegador não valida o redirecionamento nem o fluxo da API de um cliente nativo.

Teste explicitamente cada combinação suportada: navegador na LAN, navegador remoto, aplicação móvel na LAN e aplicação móvel remota. Registe o URL exato e a etapa da falha. Se apenas um contexto falhar, compare a cadeia de certificados, o URI de redirecionamento, o tratamento de cookies ou tokens e a rota DNS antes de alterar as permissões partilhadas dos utilizadores.

O proxy deve preservar o contexto do pedido

Um proxy inverso termina ou encaminha o transporte antes de os pedidos chegarem ao Immich. A aplicação pode depender do esquema, do anfitrião e das informações do cliente encaminhados para gerar ligações ou avaliar o contexto do pedido. Uma tradução incorreta pode fazer com que os retornos apontem para a origem errada ou fazer com que uma sessão válida pareça inconsistente.

O artigo da ZimaSpace sobre o caminho de dados do Immich salienta que o comportamento visível da aplicação atravessa várias dependências, e não apenas a fronteira de um contentor. A autenticação segue o mesmo raciocínio: DNS, terminação TLS, encaminhamento do proxy, a aplicação e qualquer fornecedor de identidade participam antes de um pedido autenticado de multimédia ser bem-sucedido.

Inspecione o registo de rede do navegador ou os registos do proxy móvel desde o início de sessão até um pedido autenticado à API. Confirme que o esquema e o anfitrião visíveis externamente permanecem consistentes nos redirecionamentos. Em seguida, verifique se a aplicação recebe as informações de encaminhamento pretendidas. Altere uma definição do proxy de cada vez e preserve um caminho LAN conhecido por funcionar.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique a continuidade da sessão com uma matriz de caminhos

Crie linhas para navegador e aplicação móvel, com colunas para acesso LAN e remoto. Em cada célula, teste um início de sessão novo, o recarregamento da página ou da cronologia, o reinício da aplicação, a renovação do token após algum tempo, o encerramento de sessão e o acesso a um recurso pertencente a outra conta de teste. Nunca utilize fotografias exclusivas de produção para testar permissões.

Um guia de acesso remoto ao Immich aborda o encapsulamento HTTPS, a conectividade remota, a monitorização e a resolução de problemas. O seu valor arquitetural está em mostrar que a disponibilidade remota acrescenta uma camada de acesso à aplicação; essa camada deve ser testada sem presumir que altera a propriedade subjacente dos utilizadores ou o modelo de autorização do Immich.

Classifique as falhas pela primeira etapa interrompida: acessibilidade, TLS, redirecionamento, aceitação das credenciais, persistência da sessão ou autorização do recurso. A matriz só está completa quando forem observados tanto o sucesso como a recusa prevista. Uma sessão que permanece iniciada, mas expõe os recursos do utilizador errado, não constitui um sucesso de autenticação.