Hur hanterar Immich autentisering för lokala och fjärranslutna sessioner?
Immich behåller kontots identitet på serversidan, medan lokala och fjärranslutna klienter presenterar sessionsuppgifter via sökvägar som kan skilja sig åt vad gäller ursprung, proxy och omdirigeringar.
Användaren kan vara densamma på LAN och bortifrån hemmet, men webbläsaren, mobilappen, reverse proxyn och identitetsleverantören hanterar inte alla övergångar på samma sätt. Autentiseringsfel bör därför spåras från utfärdandet av autentiseringsuppgifterna via transporten till serverns validering.
Identitet och sessionsuppgifter är olika lager
Autentiseringen bekräftar först en identitet, varefter efterföljande begäranden innehåller sessionsinformation som servern validerar. Ett korrekt lösenord eller resultat från en identitetsleverantör kan förekomma samtidigt som senare sessionsfel, om en token saknas, har löpt ut, lagras under ett annat ursprung eller skickas via en sökväg som servern tolkar annorlunda.
En oberoende guide om att konfigurera Authelia OIDC för Immich visar hur en extern identitetsleverantör deltar i inloggningen medan Immich fortfarande är målappen. Detta tydliggör gränsen: leverantören fastställer identiteten genom omdirigeringar, men Immich kopplar fortfarande resultatet till sin egen användare och sina egna sessioner.
Vid felsökning bör du notera om felet uppstår innan autentiseringsuppgifterna godkänns, under omdirigeringsåterkopplingen eller vid en senare API-begäran. Dessa punkter pekar på olika komponenter. Upprepade lösenordsåterställningar kan inte åtgärda en felaktig återkopplingsadress, och proxyändringar kan inte reparera ett inaktiverat Immich-konto.
Lokala och fjärranslutna URL:er skapar olika klientkontexter
En lokal adress och ett offentligt värdnamn kan nå samma Immich-container, men klienterna ser olika scheman, värdar, certifikat, DNS-svar och proxyhoppar. Webbläsare delar upp lagring efter ursprung, medan inbyggda klienter kan ha egna regler för omdirigeringar och certifikat. Sessionskontinuitet följer inte automatiskt med över dessa gränser.
Ett fall i Caddy-communityt beskriver hur Authelia fungerar för Immich i en webbläsare medan mobilappen ger fel. Det gäller en specifik proxydesign, men visar den bredare poängen: lyckad autentisering i webbläsaren bekräftar inte den inbyggda klientens omdirigerings- och API-flöde.
Testa varje kombination som stöds uttryckligen: LAN-webbläsare, fjärransluten webbläsare, LAN-mobil och fjärransluten mobil. Notera den exakta URL:en och steget där felet uppstår. Om bara en kontext misslyckas bör du jämföra dess certifikatkedja, omdirigerings-URI, hantering av cookies eller token samt DNS-rutt innan du ändrar gemensamma användarbehörigheter.
Proxyn måste bevara begärandets kontext
En reverse proxy avslutar eller vidarebefordrar transporten innan begärandena når Immich. Applikationen kan vara beroende av vidarebefordrat schema, värd och klientinformation för att generera länkar eller bedöma begärandets kontext. Felaktig översättning kan göra att återkopplingar pekar på fel ursprung eller få en annars giltig session att verka inkonsekvent.
ZimaSpaces artikel om Immichs datasökväg betonar att applikationens synliga beteende passerar genom flera beroenden snarare än en enda containergräns. Autentisering följer samma logik: DNS, TLS-terminering, proxyrouting, applikationen och eventuell identitetsleverantör deltar alla innan en autentiserad mediebegäran lyckas.
Granska webbläsarens nätverksspårning eller mobilens proxyloggar från den första inloggningen till en autentiserad API-begäran. Bekräfta att det externt synliga schemat och värdnamnet förblir konsekventa vid omdirigeringar. Kontrollera sedan att applikationen tar emot avsedd vidarebefordringsinformation. Ändra en proxyinställning i taget och behåll en känd fungerande LAN-sökväg.
Verifiera sessionskontinuitet med en sökvägsmatris
Skapa rader för webbläsare och mobil, med kolumner för LAN- och fjärråtkomst. Testa färsk inloggning, omladdning av sida eller tidslinje, omstart av applikationen, tokenförnyelse efter en tidsfördröjning, utloggning samt åtkomst till ett objekt som ägs av ett annat testkonto i varje ruta. Använd aldrig enbart produktionsfoton för behörighetstester.
En säker guide för fjärråtkomst till Immich behandlar HTTPS-tunnling, fjärranslutning, övervakning och felsökning. Dess arkitektoniska värde är att fjärråtkomst lägger till ett åtkomstlager runt applikationen; det lagret måste testas utan att man antar att det ändrar Immichs underliggande modell för användarägande eller behörighet.
Klassificera fel efter det första steget som bryts: nåbarhet, TLS, omdirigering, godkännande av autentiseringsuppgifter, sessionsbeständighet eller behörighet till objekt. Matrisen är komplett först när både lyckade resultat och avsedda nekanden har observerats. En session som förblir inloggad men visar fel användares objekt är inte en lyckad autentisering.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Immichs tillstånd, och vilka delar måste bevaras?
Immich-tillståndet omfattar original, databasrelationer, identitet, konfiguration och härledda filer; bevara varje del utifrån om den kan återskapas.
Vad gör att Immichs sökningar eller frågeresultat blir långsammare när datamängden växer?
Immich-tillväxt kan göra index större, tränga undan ofta använda sidor, komplicera filter och fördröja mediedistributionen; separera dessa steg innan du finjusterar.
Varför beter sig Immich annorlunda efter en omstart av containern?
Efter en omstart av Immich är tillfällig cacheförlust förväntad; bestående ändringar av inloggning, databas eller media tyder på beroende- eller persistensfel.
