Immich는 로컬 및 원격 세션에서 인증을 어떻게 처리하나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How Does Immich Handle Authentication Across Local and Remote Sessions?

Immich는 계정 ID를 서버 측에 유지하는 한편, 로컬 및 원격 클라이언트는 출처, 프록시, 리디렉션에 따라 달라질 수 있는 경로를 통해 세션 자격 증명을 전달합니다.

집 안의 LAN과 외부에서 동일한 사용자일 수 있지만, 브라우저, 모바일 앱, 리버스 프록시, ID 공급자가 모든 전환을 동일하게 처리하는 것은 아닙니다. 따라서 인증 실패는 자격 증명 발급부터 전송, 서버 검증까지 추적해야 합니다.

ID와 세션 자격 증명은 서로 다른 계층입니다

인증은 먼저 ID를 증명한 다음, 후속 요청에서 서버가 검증하는 세션 정보를 제시하는 방식으로 이루어집니다. 올바른 비밀번호나 ID 공급자의 인증 결과가 있더라도 토큰이 누락되었거나 만료되었거나 다른 출처에 저장되었거나, 서버가 다르게 해석하는 경로를 통해 전송되면 이후 세션이 실패할 수 있습니다.

Immich용 Authelia OIDC 구성에 관한 독립적인 가이드는 외부 ID 공급자가 로그인에 참여하는 동안 Immich가 대상 애플리케이션으로 남는 방식을 보여 줍니다. 이를 통해 경계를 명확히 알 수 있습니다. 공급자는 리디렉션을 통해 ID를 확립하지만, Immich는 여전히 그 결과를 자체 사용자 및 세션 동작에 매핑합니다.

문제를 해결할 때 실패가 자격 증명이 승인되기 전인지, 리디렉션 콜백 중인지, 이후 API 요청에서 발생하는지 기록하세요. 각 지점은 서로 다른 구성 요소를 가리킵니다. 비밀번호를 반복해서 재설정해도 콜백 URL 불일치는 해결되지 않으며, 프록시를 수정해도 비활성화된 Immich 계정을 복구할 수는 없습니다.

로컬 및 원격 URL은 서로 다른 클라이언트 컨텍스트를 만듭니다

로컬 주소와 공개 호스트 이름이 동일한 Immich 컨테이너에 연결될 수는 있지만, 클라이언트가 인식하는 스킴, 호스트, 인증서, DNS 응답, 프록시 홉은 서로 다릅니다. 브라우저는 출처별로 저장소를 분리하며, 네이티브 클라이언트는 자체 리디렉션 및 인증서 규칙을 적용할 수 있습니다. 세션 연속성이 이러한 경계를 자동으로 넘나드는 것은 아닙니다.

Caddy 커뮤니티 사례에서는 웹 브라우저에서 Authelia가 Immich와 함께 정상 작동하지만 모바일 앱에서는 오류가 발생한다고 보고합니다. 이는 하나의 프록시 설계 사례이지만, 브라우저 인증 성공만으로는 네이티브 클라이언트의 리디렉션 및 API 흐름을 검증할 수 없다는 더 넓은 점을 보여 줍니다.

지원되는 각 조합을 명시적으로 테스트하세요. LAN 브라우저, 원격 브라우저, LAN 모바일, 원격 모바일을 각각 확인합니다. 정확한 URL과 실패 단계를 기록하세요. 하나의 컨텍스트에서만 문제가 발생한다면 공유 사용자 권한을 변경하기 전에 인증서 체인, 리디렉션 URI, 쿠키 또는 토큰 처리, DNS 경로를 비교하세요.

프록시는 요청 컨텍스트를 보존해야 합니다

리버스 프록시는 요청이 Immich에 도달하기 전에 전송을 종료하거나 전달합니다. 애플리케이션은 링크를 생성하거나 요청 컨텍스트를 평가하기 위해 전달된 스킴, 호스트, 클라이언트 정보를 사용할 수 있습니다. 이를 잘못 변환하면 콜백이 잘못된 출처를 가리키거나, 정상적인 세션이 일관되지 않은 것으로 보일 수 있습니다.

ZimaSpace의 Immich 데이터 경로 문서는 눈에 보이는 애플리케이션 동작이 하나의 컨테이너 경계를 넘어 여러 종속 요소를 거친다는 점을 강조합니다. 인증도 같은 방식으로 이해할 수 있습니다. 인증된 미디어 요청이 성공하기 전까지 DNS, TLS 종료, 프록시 라우팅, 애플리케이션, 그리고 모든 ID 공급자가 함께 관여합니다.

초기 로그인부터 인증된 API 요청 하나가 완료될 때까지 브라우저 네트워크 추적 또는 모바일 프록시 로그를 확인하세요. 리디렉션 과정에서 외부에 표시되는 스킴과 호스트가 일관되게 유지되는지 확인합니다. 그런 다음 애플리케이션이 의도한 전달 정보를 받는지 검증하세요. 프록시 설정은 한 번에 하나씩 변경하고, 정상 작동하는 LAN 경로는 유지하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

경로 매트릭스로 세션 연속성 확인

브라우저와 모바일을 행으로, LAN과 원격 액세스를 열로 구성하세요. 각 셀에서 새 로그인, 페이지 또는 타임라인 새로고침, 애플리케이션 재시작, 일정 시간이 지난 후 토큰 갱신, 로그아웃, 다른 테스트 계정이 소유한 자산에 대한 접근을 테스트합니다. 권한 테스트에 운영 환경에서만 사용하는 사진을 절대 사용하지 마세요.

Immich를 위한 안전한 원격 액세스 가이드는 HTTPS 터널링, 원격 연결, 모니터링, 문제 해결을 다룹니다. 이 가이드의 구조적 가치는 원격 사용 가능성이 애플리케이션 주변에 액세스 계층을 추가한다는 점에 있습니다. 이 계층은 Immich의 기본 사용자 소유권이나 권한 부여 모델이 변경된다고 가정하지 않고 테스트해야 합니다.

실패를 처음 문제가 발생한 단계에 따라 도달 가능성, TLS, 리디렉션, 자격 증명 승인, 세션 지속성, 자산 권한 부여로 분류하세요. 성공과 의도된 거부가 모두 관찰되어야 매트릭스가 완성됩니다. 로그인 상태가 유지되더라도 잘못된 사용자의 자산이 노출된다면 인증 성공이 아닙니다.