Immichはローカルセッションとリモートセッションの認証をどのように処理しますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Immich Handle Authentication Across Local and Remote Sessions?

Immichはアカウントのアイデンティティをサーバー側で管理し、ローカルおよびリモートのクライアントは、オリジン、プロキシ、リダイレクトによって異なる場合がある経路を通じてセッション認証情報を提示します。

自宅内でも外出先でも同じユーザーである可能性がありますが、ブラウザー、モバイルアプリ、リバースプロキシ、アイデンティティプロバイダーは、すべての遷移を同じようには処理しません。そのため、認証失敗は認証情報の発行から、転送、サーバーでの検証まで追跡する必要があります。

アイデンティティとセッション認証情報は異なるレイヤー

認証ではまずアイデンティティを証明し、その後のリクエストでサーバーが検証するセッション情報を提示します。正しいパスワードやアイデンティティプロバイダーの結果が得られていても、トークンがない、期限切れになっている、別のオリジンに保存されている、またはサーバーが異なる形で解釈する経路を通っている場合、後続のセッションが失敗することがあります。

Immich向けのAuthelia OIDC設定ガイドでは、外部アイデンティティプロバイダーがサインオンに参加しつつ、Immichが移行先のアプリケーションとして動作する構成を紹介しています。ここから境界が明確になります。プロバイダーはリダイレクトを通じてアイデンティティを確立しますが、結果を自身のユーザーとセッションの動作に対応付けるのは依然としてImmichです。

デバッグ時には、認証情報が受け入れられる前、リダイレクトのコールバック中、または後続のAPIリクエストのどの段階で失敗したかを記録してください。これらの箇所は、それぞれ異なるコンポーネントを示します。パスワードを繰り返しリセットしても、コールバックURLの不一致は解決できません。また、プロキシを編集しても、無効化されたImmichアカウントは修復できません。

ローカルURLとリモートURLは異なるクライアントコンテキストを作る

ローカルアドレスと公開ホスト名が同じImmichコンテナに到達する場合でも、クライアントから見えるスキーム、ホスト、証明書、DNSの応答、プロキシの経路は異なります。ブラウザーはオリジンごとにストレージを分離し、ネイティブクライアントは独自のリダイレクトや証明書のルールを適用することがあります。セッションの継続性が、これらの境界を自動的に越えるとは限りません。

Caddyコミュニティの事例では、WebブラウザーではAutheliaがImmichで動作する一方、モバイルアプリではエラーが発生すると報告されています。これは1つのプロキシ構成に関する事例ですが、ブラウザー認証に成功しても、ネイティブクライアントのリダイレクトおよびAPIフローまで検証できたことにはならない、という一般的な点を示しています。

対応する組み合わせをそれぞれ明示的にテストしてください。LANブラウザー、リモートブラウザー、LANモバイル、リモートモバイルを用意します。正確なURLと失敗した手順を記録してください。1つのコンテキストだけが失敗する場合は、共有ユーザー権限を変更する前に、そのコンテキストの証明書チェーン、リダイレクトURI、Cookieまたはトークンの処理、DNS経路を比較します。

プロキシはリクエストのコンテキストを維持する必要がある

リバースプロキシは、リクエストがImmichに到達する前に、転送を終端または中継します。アプリケーションは、リンクの生成やリクエストコンテキストの評価に、転送されたスキーム、ホスト、クライアント情報を利用する場合があります。誤った変換により、コールバックが誤ったオリジンを指したり、正しいセッションが一貫しないものとして扱われたりする可能性があります。

ZimaSpaceのImmichデータパスの記事では、目に見えるアプリケーションの動作が、単一のコンテナ境界ではなく、複数の依存関係をまたぐことを強調しています。認証も同じ考え方に従います。認証済みのメディアリクエストが成功するまでには、DNS、TLS終端、プロキシルーティング、アプリケーション、そしてアイデンティティプロバイダーが関与します。

初回ログインから認証済みAPIリクエストを1つ実行するまでのブラウザーネットワークトレース、またはモバイルのプロキシログを確認してください。リダイレクト時に外部から見えるスキームとホストが一貫していることを確認します。次に、アプリケーションが意図した転送情報を受け取っていることを検証します。プロキシ設定は一度に1つだけ変更し、既知の正常なLAN経路を維持してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

パスマトリックスでセッションの継続性を検証する

行にブラウザーとモバイルを、列にLANアクセスとリモートアクセスを配置します。各セルで、新規ログイン、ページまたはタイムラインの再読み込み、アプリケーションの再起動、時間経過後のトークン更新、ログアウト、別のテストアカウントが所有するアセットへのアクセスをテストしてください。権限テストに本番環境専用の写真を使用してはいけません。

Immich向けの安全なリモートアクセスガイドでは、HTTPSトンネリング、リモート接続、監視、トラブルシューティングを扱っています。このガイドのアーキテクチャ上の価値は、リモート利用がアプリケーションの周囲にアクセスレイヤーを追加する点にあります。そのレイヤーは、Immichの基盤となるユーザー所有権や認可モデルを変更すると仮定せずにテストする必要があります。

失敗を、最初に壊れた手順で分類してください。到達性、TLS、リダイレクト、認証情報の受け入れ、セッションの永続性、アセット認可のいずれかです。マトリックスは、成功と意図した拒否の両方が確認できて初めて完成します。ログイン状態が維持されていても、別のユーザーのアセットが表示されるなら、それは認証の成功ではありません。