Comment Immich gère-t-il l’authentification entre les sessions locales et distantes ?
Immich conserve l’identité du compte côté serveur, tandis que les clients locaux et distants présentent leurs identifiants de session via des chemins qui peuvent différer par leur origine, leur proxy et leurs redirections.
L’utilisateur peut être identique sur le réseau local et à l’extérieur du domicile, mais le navigateur, l’application mobile, le proxy inverse et le fournisseur d’identité ne gèrent pas toutes les transitions de la même manière. Les échecs d’authentification doivent donc être suivis depuis l’émission des identifiants jusqu’au transport, puis à leur validation par le serveur.
L’identité et les identifiants de session sont deux couches différentes
L’authentification commence par vérifier une identité, puis les requêtes suivantes présentent des éléments de session que le serveur valide. Un mot de passe correct ou un résultat correct du fournisseur d’identité peut coexister avec un échec de session ultérieur si un jeton est absent, expiré, enregistré sous une autre origine ou transmis par un chemin que le serveur interprète différemment.
Un guide indépendant consacré à la configuration d’Authelia OIDC pour Immich montre un fournisseur d’identité externe participer à la connexion, tandis qu’Immich reste l’application cible. Cela clarifie la frontière : le fournisseur établit l’identité par des redirections, mais Immich associe toujours le résultat à son propre utilisateur et à son propre comportement de session.
Lors du débogage, notez si l’échec survient avant l’acceptation des identifiants, pendant le rappel de redirection ou lors d’une requête API ultérieure. Ces étapes mettent en cause des composants différents. Réinitialiser les mots de passe à répétition ne peut pas corriger une incompatibilité d’URL de rappel, et modifier le proxy ne peut pas réactiver un compte Immich désactivé.
Les URL locales et distantes créent des contextes client différents
Une adresse locale et un nom d’hôte public peuvent atteindre le même conteneur Immich, mais les clients voient des schémas, des hôtes, des certificats, des réponses DNS et des sauts de proxy différents. Les navigateurs cloisonnent le stockage par origine, tandis que les clients natifs peuvent appliquer leurs propres règles de redirection et de certificat. La continuité de session ne franchit pas automatiquement ces frontières.
Un cas présenté sur la communauté Caddy décrit Authelia fonctionnant avec Immich dans un navigateur web, tandis que l’application mobile génère des erreurs. Il s’agit d’une conception de proxy particulière, mais cela illustre le principe général : la réussite de l’authentification dans un navigateur ne valide pas le flux de redirection et d’API d’un client natif.
Testez explicitement chaque combinaison prise en charge : navigateur sur le réseau local, navigateur à distance, mobile sur le réseau local et mobile à distance. Notez l’URL exacte et l’étape d’échec. Si un seul contexte échoue, comparez sa chaîne de certificats, son URI de redirection, la gestion des cookies ou des jetons et son itinéraire DNS avant de modifier les autorisations partagées des utilisateurs.
Le proxy doit préserver le contexte de la requête
Un proxy inverse termine ou transmet le transport avant que les requêtes n’atteignent Immich. L’application peut dépendre du schéma, de l’hôte et des informations client transmis pour générer des liens ou évaluer le contexte de la requête. Une traduction incorrecte peut faire pointer les rappels vers la mauvaise origine ou faire paraître incohérente une session pourtant valide.
L’article de ZimaSpace sur le chemin des données d’Immich souligne que le comportement visible de l’application traverse plusieurs dépendances plutôt qu’une seule limite de conteneur. L’authentification suit le même raisonnement : le DNS, la terminaison TLS, le routage du proxy, l’application et tout fournisseur d’identité participent au processus avant qu’une requête multimédia authentifiée n’aboutisse.
Examinez la trace réseau du navigateur ou les journaux du proxy mobile depuis la connexion initiale jusqu’à une requête API authentifiée. Vérifiez que le schéma et l’hôte visibles de l’extérieur restent cohérents lors des redirections. Vérifiez ensuite que l’application reçoit les informations de transmission attendues. Modifiez un seul paramètre du proxy à la fois et conservez un chemin local connu comme fonctionnel.
Vérifiez la continuité de session avec une matrice des chemins
Créez des lignes pour le navigateur et le mobile, avec des colonnes pour l’accès local et distant. Dans chaque cellule, testez une nouvelle connexion, le rechargement d’une page ou de la chronologie, le redémarrage de l’application, le renouvellement du jeton après un certain délai, la déconnexion et l’accès à un élément appartenant à un autre compte de test. N’utilisez jamais de photos réservées à la production pour tester les autorisations.
Un guide d’accès à distance sécurisé pour Immich couvre le tunneling HTTPS, la connectivité distante, la surveillance et le dépannage. Son intérêt architectural est que la disponibilité à distance ajoute une couche d’accès autour de l’application ; cette couche doit être testée sans supposer qu’elle modifie la propriété sous-jacente des utilisateurs ou le modèle d’autorisation d’Immich.
Classez les échecs selon la première étape défaillante : accessibilité, TLS, redirection, acceptation des identifiants, persistance de session ou autorisation d’accès aux éléments. La matrice n’est complète que lorsque la réussite et le refus attendu ont tous deux été observés. Une session qui reste ouverte mais expose les éléments d’un autre utilisateur ne constitue pas une réussite de l’authentification.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que l’état d’Immich et quelles parties doivent être persistantes ?
L’état d’Immich comprend les originaux, les relations de la base de données, l’identité, la configuration et les dérivés ; conservez chacun selon qu’il peut...
Qu’est-ce qui ralentit les recherches ou les résultats de requêtes Immich à mesure que les données augmentent ?
La croissance d’Immich peut augmenter la taille des index, évincer les pages fréquemment utilisées, complexifier les filtres et retarder la diffusion des médias ;...
Pourquoi Immich se comporte-t-il différemment après le redémarrage d’un conteneur ?
Après un redémarrage d’Immich, une perte temporaire du cache est normale ; des problèmes persistants de connexion, de base de données ou de fichiers...
