Différences d’authentification de Jellyfin entre les sessions locales et distantes

Jellyfin utilise le même modèle d’identité et d’autorisation côté serveur, mais les sessions locales et distantes parviennent à cette décision via des chemins réseau différents.

Un client local peut utiliser un adressage direct ou la découverte, tandis qu’un client distant peut traverser des couches de DNS, de routage, de pare-feu, de NAT, de VPN ou de proxy. Une connexion réussie prouve donc l’identité de l’utilisateur, mais pas que le chemin distant permettra une lecture fluide. Traitez l’authentification et l’accessibilité comme deux questions distinctes.

L’identité constitue la couche de confiance

Le serveur doit identifier l’utilisateur actif avant de pouvoir appliquer les droits d’accès aux bibliothèques, l’état de visionnage et les règles. Le fait que l’utilisateur soit connecté localement ou à distance ne crée pas, en soi, une identité différente ; cela modifie seulement la manière dont le client atteint le serveur.

Le modèle des rôles de données persistantes explique pourquoi l’identité doit être testée séparément du transport et des capacités du client.

Si deux appareils affichent des bibliothèques différentes pour le même compte, vérifiez l’identité de la session et les autorisations avant d’accuser le routage.

Les sessions locales ont généralement moins de dépendances réseau

Un client du réseau local peut utiliser une adresse privée directe, une bande passante stable et la découverte locale. Ces conditions réduisent le nombre de couches externes susceptibles de tomber en panne, mais elles ne modifient pas la décision d’autorisation une fois la requête parvenue à Jellyfin.

Comparez le chemin local au modèle d’accessibilité en couches : la découverte, le DNS, le routage et les règles sont distincts, même au sein d’un réseau domestique.

Une connexion locale réussie prouve qu’un chemin fonctionne. Elle ne prouve pas que le nom d’hôte distant, le proxy ou le VPN fournira le même itinéraire.

Les sessions distantes ajoutent des variables d’accessibilité et de lecture

L’accès distant peut dépendre de la traversée du NAT, du DNS, des certificats, des règles du proxy, de la bande passante montante et d’un profil client qui déclenche le transcodage. L’authentification peut réussir alors que la lecture reste lente ou impossible.

Utilisez la distinction du modèle d’accessibilité en couches entre l’identité et l’accessibilité réseau pour interpréter le résultat d’une connexion distante.

Si la connexion réussit mais que la lecture échoue, la question suivante concerne le chemin de diffusion et le mode de lecture, et non la reconnaissance de l’utilisateur par Jellyfin.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez une checklist d’authentification et de connectivité

Testez un compte connu localement et à distance, notez l’utilisateur et la bibliothèque affichés, puis testez séparément une lecture directe et une lecture à distance. Conservez les mêmes contenus et autorisations en ne modifiant que le chemin.

La comparaison du comportement des clients Jellyfin aide à ne pas confondre l’identité de l’utilisateur, les autorisations de bibliothèque et le transport de la lecture en un seul symptôme.

Arrêtez-vous dès que la panne est clairement attribuée à l’identité, à l’autorisation, à l’accessibilité ou à la capacité de lecture. Chaque limite relève d’un responsable différent et laisse des éléments de preuve distincts.