Wie handhabt Immich die Authentifizierung bei lokalen und Remote-Sitzungen?

Immich hält die Kontoidentität serverseitig vor, während lokale und entfernte Clients Sitzungsdaten über Pfade übermitteln, die sich hinsichtlich Ursprung, Proxy und Weiterleitungen unterscheiden können.

Der Benutzer kann im LAN und außerhalb des Zuhauses derselbe sein, doch Browser, mobile App, Reverse-Proxy und Identitätsanbieter behandeln nicht jeden Übergang gleich. Authentifizierungsfehler sollten daher von der Ausstellung der Zugangsdaten über den Transport bis zur Servervalidierung zurückverfolgt werden.

Identität und Sitzungsdaten sind unterschiedliche Ebenen

Bei der Authentifizierung wird zunächst eine Identität bestätigt. Anschließende Anfragen übermitteln Sitzungsdaten, die der Server validiert. Ein korrektes Passwort oder ein erfolgreiches Ergebnis des Identitätsanbieters kann mit einem späteren Sitzungsfehler einhergehen, wenn ein Token fehlt, abgelaufen ist, unter einem anderen Ursprung gespeichert wurde oder über einen Pfad gesendet wird, den der Server anders interpretiert.

Ein unabhängiger Leitfaden zur Konfiguration von Authelia OIDC für Immich zeigt, wie ein externer Identitätsanbieter an der Anmeldung beteiligt ist, während Immich die Zielanwendung bleibt. Das verdeutlicht die Abgrenzung: Der Anbieter stellt die Identität über Weiterleitungen fest, aber Immich ordnet das Ergebnis weiterhin seinem eigenen Benutzer- und Sitzungsverhalten zu.

Halten Sie beim Debugging fest, ob der Fehler auftritt, bevor Zugangsdaten akzeptiert werden, während des Weiterleitungs-Callbacks oder bei einer späteren API-Anfrage. Diese Punkte weisen auf unterschiedliche Komponenten hin. Wiederholtes Zurücksetzen von Passwörtern kann keine Abweichung bei der Callback-URL beheben, und Änderungen am Proxy reparieren kein deaktiviertes Immich-Konto.

Lokale und entfernte URLs erzeugen unterschiedliche Client-Kontexte

Eine lokale Adresse und ein öffentlicher Hostname können denselben Immich-Container erreichen, aber Clients sehen unterschiedliche Schemata, Hosts, Zertifikate, DNS-Antworten und Proxy-Stationen. Browser trennen den Speicher nach Ursprung, während native Clients eigene Regeln für Weiterleitungen und Zertifikate anwenden können. Die Sitzungsfortsetzung funktioniert nicht automatisch über diese Grenzen hinweg.

Ein Fall aus der Caddy-Community berichtet, dass Authelia für Immich im Webbrowser funktioniert, während die mobile App Fehler erzeugt. Das ist nur ein bestimmtes Proxy-Design, verdeutlicht aber den übergeordneten Punkt: Eine erfolgreiche Browser-Authentifizierung bestätigt nicht den Weiterleitungs- und API-Ablauf eines nativen Clients.

Testen Sie jede unterstützte Kombination ausdrücklich: LAN-Browser, entfernter Browser, LAN-Mobilgerät und entferntes Mobilgerät. Notieren Sie die genaue URL und den Fehlerschritt. Wenn nur ein Kontext fehlschlägt, vergleichen Sie Zertifikatskette, Weiterleitungs-URI, Cookie- oder Token-Verarbeitung und DNS-Route, bevor Sie gemeinsame Benutzerberechtigungen ändern.

Der Proxy muss den Anfragekontext bewahren

Ein Reverse-Proxy beendet oder leitet den Transport weiter, bevor Anfragen Immich erreichen. Die Anwendung kann auf weitergeleitete Angaben zu Schema, Host und Client angewiesen sein, um Links zu erzeugen oder den Anfragekontext zu bewerten. Eine fehlerhafte Übersetzung kann dazu führen, dass Callbacks auf den falschen Ursprung verweisen oder eine ansonsten gültige Sitzung inkonsistent erscheint.

Der Artikel zum Immich-Datenpfad von ZimaSpace betont, dass das sichtbare Anwendungsverhalten mehrere Abhängigkeiten und nicht nur eine Containergrenze durchläuft. Für die Authentifizierung gilt dieselbe Überlegung: DNS, TLS-Terminierung, Proxy-Routing, die Anwendung und jeder Identitätsanbieter sind beteiligt, bevor eine authentifizierte Medienanfrage erfolgreich ist.

Prüfen Sie die Netzwerkaufzeichnung des Browsers oder die Proxy-Protokolle des Mobilgeräts vom ersten Login bis zu einer authentifizierten API-Anfrage. Stellen Sie sicher, dass das extern sichtbare Schema und der Host bei Weiterleitungen konsistent bleiben. Überprüfen Sie anschließend, ob die Anwendung die vorgesehenen Weiterleitungsinformationen erhält. Ändern Sie jeweils nur eine Proxy-Einstellung und bewahren Sie einen bekanntermaßen funktionierenden LAN-Pfad.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sitzungskontinuität mit einer Pfadmatrix überprüfen

Erstellen Sie Zeilen für Browser und Mobilgerät sowie Spalten für LAN- und Fernzugriff. Testen Sie in jeder Zelle eine frische Anmeldung, das Neuladen der Seite oder Zeitleiste, einen Neustart der Anwendung, die Token-Erneuerung nach einiger Zeit, die Abmeldung und den Zugriff auf ein Asset, das einem anderen Testkonto gehört. Verwenden Sie für Berechtigungstests niemals ausschließlich in der Produktion vorhandene Fotos.

Ein sicherer Leitfaden für den Fernzugriff auf Immich behandelt HTTPS-Tunneling, entfernte Konnektivität, Überwachung und Fehlerbehebung. Sein architektonischer Wert besteht darin, dass die entfernte Verfügbarkeit eine Zugriffsebene um die Anwendung herum ergänzt. Diese Ebene muss getestet werden, ohne anzunehmen, dass sie Immichs zugrunde liegendes Modell für Benutzereigentum oder Autorisierung verändert.

Klassifizieren Sie Fehler nach dem ersten fehlgeschlagenen Schritt: Erreichbarkeit, TLS, Weiterleitung, Akzeptanz der Zugangsdaten, Sitzungsfortbestand oder Asset-Autorisierung. Die Matrix ist erst vollständig, wenn sowohl Erfolg als auch die vorgesehene Verweigerung beobachtet wurden. Eine Sitzung, die angemeldet bleibt, aber die Assets des falschen Benutzers offenlegt, ist kein Authentifizierungserfolg.