Hoe gaat Immich om met authenticatie voor lokale en externe sessies?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How Does Immich Handle Authentication Across Local and Remote Sessions?

Immich bewaart de accountidentiteit aan de serverzijde, terwijl lokale en externe clients sessiegegevens aanbieden via paden die kunnen verschillen in oorsprong, proxy en omleidingen.

De gebruiker kan op het LAN en buitenshuis dezelfde zijn, maar de browser, mobiele app, reverse proxy en identityprovider verwerken niet elke overgang op dezelfde manier. Authenticatiefouten moeten daarom worden gevolgd vanaf het uitgeven van de inloggegevens, via het transport, tot aan de servervalidatie.

Identiteit en sessiegegevens zijn verschillende lagen

Authenticatie bewijst eerst een identiteit; bij volgende verzoeken worden sessiegegevens meegestuurd die de server valideert. Een correct wachtwoord of resultaat van een identityprovider kan samengaan met een latere sessiefout als een token ontbreekt, verlopen is, onder een andere oorsprong is opgeslagen of via een pad wordt verzonden dat de server anders interpreteert.

Een onafhankelijke handleiding voor het configureren van Authelia OIDC voor Immich laat zien hoe een externe identityprovider deelneemt aan het aanmelden, terwijl Immich de doelapplicatie blijft. Dit verduidelijkt de grens: de provider stelt via omleidingen de identiteit vast, maar Immich koppelt het resultaat nog steeds aan zijn eigen gebruiker en sessiegedrag.

Noteer bij het oplossen van problemen of de fout optreedt voordat de inloggegevens zijn geaccepteerd, tijdens de callback van de omleiding of bij een later API-verzoek. Die punten wijzen op verschillende componenten. Herhaaldelijk wachtwoorden resetten kan een mismatch in de callback-URL niet oplossen, en proxywijzigingen kunnen een uitgeschakeld Immich-account niet herstellen.

Lokale en externe URL's creëren verschillende clientcontexten

Een lokaal adres en een openbare hostnaam kunnen dezelfde Immich-container bereiken, maar clients zien verschillende schema's, hosts, certificaten, DNS-antwoorden en proxylagen. Browsers scheiden opslag per oorsprong, terwijl native clients hun eigen regels voor omleidingen en certificaten kunnen toepassen. Sessiecontinuïteit gaat niet automatisch over die grenzen heen.

Een geval uit de Caddy-community beschrijft dat Authelia voor Immich in een webbrowser werkt, terwijl de mobiele app fouten geeft. Dat is één proxyontwerp, maar het illustreert het bredere punt dat succesvolle browserauthenticatie de omleidings- en API-stroom van een native client niet valideert.

Test elke ondersteunde combinatie expliciet: LAN-browser, externe browser, LAN-mobiel en externe mobiel. Noteer de exacte URL en de stap waarop de fout optreedt. Als slechts één context faalt, vergelijk dan eerst de certificaatketen, omleidings-URI, verwerking van cookies of tokens en DNS-route voordat je gedeelde gebruikersrechten wijzigt.

De proxy moet de verzoekcontext behouden

Een reverse proxy beëindigt of doorstuurt transport voordat verzoeken Immich bereiken. De applicatie kan afhankelijk zijn van doorgestuurde informatie over schema, host en client om links te genereren of de verzoekcontext te beoordelen. Een onjuiste vertaling kan ervoor zorgen dat callbacks naar de verkeerde oorsprong verwijzen of dat een verder geldige sessie inconsistent lijkt.

Het Immich-datapadartikel van ZimaSpace benadrukt dat zichtbaar applicatiegedrag meerdere afhankelijkheden doorkruist en niet slechts één containergrens. Voor authenticatie geldt dezelfde redenering: DNS, TLS-beëindiging, proxyrouting, de applicatie en eventuele identityproviders nemen allemaal deel voordat een geauthenticeerd mediaverzoek slaagt.

Bekijk de netwerktrace van de browser of de proxylogboeken van de mobiele client vanaf het eerste aanmelden tot en met één geauthenticeerd API-verzoek. Controleer of het extern zichtbare schema en de host bij omleidingen consistent blijven. Controleer vervolgens of de applicatie de bedoelde doorgestuurde informatie ontvangt. Wijzig telkens één proxyinstelling en behoud een bekende werkende LAN-route.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Controleer sessiecontinuïteit met een padmatrix

Maak rijen voor browser en mobiel, met kolommen voor LAN- en externe toegang. Test in elke cel een nieuwe aanmelding, het opnieuw laden van een pagina of tijdlijn, het opnieuw starten van de applicatie, tokenvernieuwing nadat er tijd is verstreken, afmelden en toegang tot een item dat eigendom is van een andere testaccount. Gebruik nooit uitsluitend productiefoto's voor permissietests.

Een veilige handleiding voor externe toegang tot Immich behandelt HTTPS-tunneling, externe connectiviteit, monitoring en probleemoplossing. De architectonische waarde ervan is dat externe beschikbaarheid een toegangslaag rond de applicatie toevoegt; die laag moet worden getest zonder aan te nemen dat ze Immichs onderliggende model voor gebruikerseigendom of autorisatie verandert.

Deel fouten in op basis van de eerste stap die niet werkt: bereikbaarheid, TLS, omleiding, acceptatie van inloggegevens, sessiebehoud of autorisatie voor items. De matrix is pas compleet wanneer zowel succes als de beoogde weigering zijn waargenomen. Een sessie die ingelogd blijft maar de items van de verkeerde gebruiker toont, is geen succesvolle authenticatie.