Jak Immich obsługuje uwierzytelnianie w sesjach lokalnych i zdalnych?

Immich przechowuje tożsamość konta po stronie serwera, podczas gdy klienci lokalni i zdalni przekazują dane uwierzytelniające sesji za pośrednictwem ścieżek, które mogą różnić się źródłem, serwerem proxy i przekierowaniami.

Użytkownik może być identyczny zarówno w sieci LAN, jak i poza domem, jednak przeglądarka, aplikacja mobilna, odwrotny serwer proxy i dostawca tożsamości nie obsługują każdej zmiany w taki sam sposób. Dlatego błędy uwierzytelniania należy śledzić od wydania danych uwierzytelniających, przez transport, aż po walidację na serwerze.

Tożsamość i dane uwierzytelniające sesji to różne warstwy

Uwierzytelnianie najpierw potwierdza tożsamość, a następnie kolejne żądania przekazują dane sesji, które serwer weryfikuje. Prawidłowe hasło lub wynik działania dostawcy tożsamości mogą współistnieć z późniejszym błędem sesji, jeśli brakuje tokenu, token wygasł, został zapisany dla innego źródła albo wysłano go ścieżką, którą serwer interpretuje inaczej.

Niezależny przewodnik dotyczący konfigurowania Authelia OIDC dla Immich pokazuje udział zewnętrznego dostawcy tożsamości w logowaniu, podczas gdy Immich pozostaje aplikacją docelową. Wyjaśnia to granicę odpowiedzialności: dostawca ustanawia tożsamość za pomocą przekierowań, ale Immich nadal przypisuje wynik do własnego użytkownika i obsługuje sesję zgodnie z własnymi zasadami.

Podczas debugowania zapisz, czy awaria występuje przed zaakceptowaniem danych uwierzytelniających, podczas obsługi przekierowania zwrotnego czy przy późniejszym żądaniu API. Każdy z tych punktów wskazuje na inne komponenty. Wielokrotne resetowanie haseł nie naprawi niezgodności adresu URL wywołania zwrotnego, a zmiany w konfiguracji proxy nie naprawią wyłączonego konta Immich.

Lokalne i zdalne adresy URL tworzą różne konteksty klienta

Adres lokalny i publiczna nazwa hosta mogą prowadzić do tego samego kontenera Immich, ale klienci widzą różne schematy, hosty, certyfikaty, odpowiedzi DNS i etapy pośrednictwa proxy. Przeglądarki rozdzielają pamięć według źródła, a klienci natywni mogą stosować własne reguły przekierowań i certyfikatów. Ciągłość sesji nie przenosi się automatycznie między tymi granicami.

Przypadek opisany w społeczności Caddy pokazuje, że Authelia działa z Immich w przeglądarce internetowej, podczas gdy aplikacja mobilna zgłasza błędy. Jest to przykład konkretnego projektu proxy, ale ilustruje szerszą zasadę: pomyślne uwierzytelnienie w przeglądarce nie potwierdza poprawności przekierowania i przepływu API klienta natywnego.

Wyraźnie przetestuj każdą obsługiwaną kombinację: przeglądarkę w sieci LAN, przeglądarkę zdalną, aplikację mobilną w sieci LAN i aplikację mobilną zdalnie. Zapisz dokładny adres URL oraz etap wystąpienia błędu. Jeśli nie działa tylko jeden kontekst, przed zmianą wspólnych uprawnień użytkownika porównaj łańcuch certyfikatów, identyfikator URI przekierowania, obsługę plików cookie lub tokenów oraz trasę DNS.

Proxy musi zachowywać kontekst żądania

Odwrotny serwer proxy kończy połączenie transportowe lub przekazuje je dalej, zanim żądania dotrą do Immich. Aplikacja może korzystać z przekazywanych informacji o schemacie, hoście i kliencie, aby generować łącza lub oceniać kontekst żądania. Nieprawidłowe tłumaczenie może kierować wywołania zwrotne do niewłaściwego źródła albo sprawiać, że prawidłowa sesja będzie wyglądać na niespójną.

Artykuł ZimaSpace o ścieżce danych Immich podkreśla, że widoczne działanie aplikacji zależy od kilku elementów, a nie od jednej granicy kontenera. To samo rozumowanie dotyczy uwierzytelniania: DNS, terminowanie TLS, routing proxy, aplikacja i ewentualny dostawca tożsamości uczestniczą w procesie, zanim uwierzytelnione żądanie multimediów zakończy się powodzeniem.

Przeanalizuj ślad sieciowy przeglądarki lub logi proxy aplikacji mobilnej od pierwszego logowania do jednego uwierzytelnionego żądania API. Potwierdź, że widoczny z zewnątrz schemat i host pozostają spójne podczas przekierowań. Następnie sprawdź, czy aplikacja otrzymuje właściwe informacje przekazywane przez proxy. Zmieniaj jedno ustawienie proxy naraz i zachowaj znaną, działającą ścieżkę LAN.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zweryfikuj ciągłość sesji za pomocą macierzy ścieżek

Utwórz wiersze dla przeglądarki i aplikacji mobilnej oraz kolumny dla dostępu z sieci LAN i zdalnego. W każdej komórce przetestuj nowe logowanie, ponowne wczytanie strony lub osi czasu, ponowne uruchomienie aplikacji, odnowienie tokenu po upływie czasu, wylogowanie oraz dostęp do zasobu należącego do innego konta testowego. Do testowania uprawnień nigdy nie używaj zdjęć dostępnych wyłącznie w środowisku produkcyjnym.

Bezpieczny przewodnik po dostępie zdalnym dla Immich obejmuje tunelowanie HTTPS, łączność zdalną, monitorowanie i rozwiązywanie problemów. Jego wartość architektoniczna polega na tym, że dostęp zdalny dodaje warstwę dostępu wokół aplikacji; warstwę tę należy testować bez zakładania, że zmienia ona podstawowy model własności użytkowników lub autoryzacji w Immich.

Klasyfikuj awarie według pierwszego nieudanego etapu: dostępność, TLS, przekierowanie, akceptacja danych uwierzytelniających, utrzymanie sesji lub autoryzacja dostępu do zasobu. Macierz jest kompletna dopiero wtedy, gdy zaobserwowano zarówno powodzenie, jak i zamierzoną odmowę dostępu. Sesja, która pozostaje aktywna, ale ujawnia zasoby niewłaściwego użytkownika, nie oznacza pomyślnego uwierzytelnienia.