Come gestisce Immich l’autenticazione tra sessioni locali e remote?
Immich mantiene l’identità dell’account lato server, mentre i client locali e remoti presentano le credenziali di sessione attraverso percorsi che possono differire per origine, proxy e reindirizzamenti.
L’utente può essere lo stesso sulla LAN e fuori casa, tuttavia browser, app mobile, proxy inverso e provider di identità non gestiscono allo stesso modo ogni passaggio. I problemi di autenticazione devono quindi essere tracciati dall’emissione delle credenziali, attraverso il trasporto, fino alla convalida sul server.
Identità e credenziali di sessione sono livelli diversi
L’autenticazione prima dimostra un’identità, poi le richieste successive presentano le informazioni di sessione che il server convalida. Una password corretta o un risultato valido del provider di identità possono coesistere con un successivo errore di sessione se manca un token, se è scaduto, se è stato memorizzato sotto un’altra origine o se è stato inviato attraverso un percorso interpretato diversamente dal server.
Una guida indipendente alla configurazione di Authelia OIDC per Immich mostra un provider di identità esterno che partecipa all’accesso, mentre Immich resta l’applicazione di destinazione. Questo chiarisce il confine: il provider stabilisce l’identità tramite reindirizzamenti, ma Immich associa comunque il risultato al proprio utente e gestisce la propria sessione.
Durante il debug, annota se l’errore si verifica prima dell’accettazione delle credenziali, durante il callback di reindirizzamento o in una successiva richiesta API. Questi punti coinvolgono componenti diversi. Reimpostare ripetutamente le password non può risolvere un’incongruenza nell’URL di callback, così come le modifiche al proxy non possono riattivare un account Immich disabilitato.
Gli URL locali e remoti creano contesti client diversi
Un indirizzo locale e un hostname pubblico possono raggiungere lo stesso container Immich, ma i client vedono schemi, host, certificati, risposte DNS e passaggi del proxy diversi. I browser separano lo spazio di archiviazione in base all’origine, mentre i client nativi possono applicare regole proprie per reindirizzamenti e certificati. La continuità della sessione non attraversa automaticamente questi confini.
Un caso nella community di Caddy descrive Authelia funzionante per Immich in un browser web, mentre l’app mobile genera errori. Si tratta di una specifica configurazione proxy, ma dimostra il punto più generale: un’autenticazione riuscita nel browser non convalida il flusso di reindirizzamento e API di un client nativo.
Testa esplicitamente ogni combinazione supportata: browser sulla LAN, browser da remoto, dispositivo mobile sulla LAN e dispositivo mobile da remoto. Annota l’URL esatto e il passaggio in cui si verifica l’errore. Se fallisce un solo contesto, confronta la catena dei certificati, l’URI di reindirizzamento, la gestione di cookie o token e il percorso DNS prima di modificare i permessi condivisi degli utenti.
Il proxy deve preservare il contesto della richiesta
Un proxy inverso termina o inoltra il trasporto prima che le richieste raggiungano Immich. L’applicazione può fare affidamento sullo schema, sull’host e sulle informazioni del client inoltrati per generare link o valutare il contesto della richiesta. Una traduzione errata può far puntare i callback all’origine sbagliata o far apparire incoerente una sessione altrimenti valida.
L’articolo sul percorso dei dati di Immich di ZimaSpace sottolinea che il comportamento visibile dell’applicazione attraversa diverse dipendenze, non un solo confine tra container. Lo stesso ragionamento vale per l’autenticazione: DNS, terminazione TLS, instradamento del proxy, applicazione ed eventuale provider di identità partecipano tutti al processo prima che una richiesta autenticata di contenuti multimediali vada a buon fine.
Esamina la traccia di rete del browser o i log del proxy mobile dal login iniziale fino a una richiesta API autenticata. Verifica che lo schema e l’host visibili esternamente restino coerenti durante i reindirizzamenti. Poi verifica che l’applicazione riceva le informazioni di inoltro previste. Modifica una sola impostazione del proxy alla volta e conserva un percorso LAN noto per funzionare.
Verifica la continuità della sessione con una matrice dei percorsi
Crea righe per browser e dispositivi mobili, con colonne per l’accesso LAN e remoto. In ogni cella, testa il login da zero, il ricaricamento della pagina o della timeline, il riavvio dell’applicazione, il rinnovo del token dopo un certo periodo, il logout e l’accesso a un contenuto appartenente a un altro account di test. Non usare mai foto esclusive dell’ambiente di produzione per testare i permessi.
Una guida all’accesso remoto per Immich tratta il tunneling HTTPS, la connettività remota, il monitoraggio e la risoluzione dei problemi. Il suo valore architetturale consiste nel fatto che la disponibilità remota aggiunge un livello di accesso attorno all’applicazione; tale livello deve essere testato senza presumere che modifichi il modello sottostante di proprietà o autorizzazione degli utenti di Immich.
Classifica gli errori in base al primo passaggio non riuscito: raggiungibilità, TLS, reindirizzamento, accettazione delle credenziali, persistenza della sessione o autorizzazione sui contenuti. La matrice è completa solo quando vengono osservati sia i casi di successo sia i dinieghi previsti. Una sessione che resta connessa ma espone i contenuti dell’utente sbagliato non rappresenta un successo dell’autenticazione.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Che cos’è lo stato di Immich e quali parti devono essere persistenti?
Lo stato di Immich include gli originali, le relazioni del database, l’identità, la configurazione e i derivati; rendi persistente ciascun elemento in base alla...
Cosa fa rallentare la ricerca o i risultati delle query in Immich con la crescita dei dati?
La crescita di Immich può ingrandire gli indici, espellere le pagine più utilizzate, complicare i filtri e ritardare la distribuzione dei contenuti multimediali; separa...
Perché Immich si comporta diversamente dopo il riavvio di un container?
Dopo il riavvio di Immich, è prevista una perdita temporanea della cache; cambiamenti persistenti nell’accesso, nel database o nei contenuti multimediali indicano problemi di...
