Connectez les agents avec un accès que vous contrôlez

Comment fonctionne la connexion

screenRIG émet des jetons d’accès signés à courte durée de vie et des jetons de rafraîchissement à longue durée de vie. Le CLI intégré conserve les deux dans son fichier de configuration privé et les renouvelle automatiquement, ainsi un agent ne manipule jamais un jeton ni ne le colle dans une conversation.

Il y a quatre façons d’entrer :

Les personnes se connectent au tableau de bord avec une clé d’accès ou un mot de passe, ou par le fournisseur d’identité de leur organisation ; voir authentification unique et provisionnement des utilisateurs.

Se connecter avec screenrig login

Utilisez screenrig login lorsque la personne possède déjà screenRIG et souhaite que cette installation d’agent fonctionne dans un de ses projets. Une nouvelle installation sans compte commence plutôt par screenrig agent enroll ; voir Démarrer.

screenrig login

1. Le CLI affiche une adresse de tableau de bord et un code de huit lettres tel que BCDF-GHJK, puis attend.
2. La personne ouvre https://screenrig.ai/dashboard/connect, se connecte et saisit le code, ou suit le lien complet qui le porte déjà.
3. Le tableau de bord affiche la demande sur un écran : le nom de l’installation rapporté par l’appareil, quand et où elle a demandé, et le code. La personne vérifie que le code correspond au terminal, ajuste le projet, le niveau d’accès ou les capacités si elle veut, puis appuie sur Connecter. Une connexion au tableau de bord datant de la dernière heure fait foi, donc Connecter ne demande rien de plus ; une connexion plus ancienne demande un passkey. Le tableau de bord ouvre alors le nouvel agent.
4. Le CLI stocke la session, sélectionne le projet approuvé et rapporte status: signed_in avec le projet, l’organisation et le niveau d’accès.

N’approuvez qu’une connexion que vous avez vous-même initiée, sur votre propre ordinateur. Le tableau de bord n’approuve jamais rien au chargement, et un code expiré nécessite un nouveau screenrig login.

Lorsque l'agent doit d'abord transmettre l'adresse à une personne via un autre canal, utilisez --no-wait. Le handle ne contient aucun secret, et la connexion en attente reste dans le fichier de configuration privé :

screenrig login --no-wait
screenrig login --resume login_HANDLE

L’adresse de connexion et son code sont pour la personne qui l’approuve. Envoyez-les uniquement à cette personne, et gardez-les hors des journaux et des canaux partagés.

Ajouter un projet ou augmenter l’accès

Une installation déjà connectée exécute screenrig login à nouveau pour ajouter un autre projet, ou pour élever un projet en lecture seule ou à proposer vers Gérer :

screenrig login --project prj_ID --access manage

La personne approuve ce changement, et l’installation conserve ses autres projets. screenrig project list montre chaque projet que l’installation peut utiliser, et screenrig project use ID en sélectionne un.

Lecture seule, proposer et gérer

Chaque session porte un des trois niveaux d’accès, choisis par la personne qui l’approuve. Chaque niveau inclut tout ce que le précédent peut faire.

Lecture seule signifie que la session ne peut rien changer ni acheter. Cela ne signifie pas gratuit : chaque requête agent et événement d’écoute facturé compte contre les requêtes incluses de l’organisation, comme pour Propose et Gérer.

Proposer permet à un agent de faire le travail tandis qu'une personne garde le dernier mot sur ce qui est diffusé. Ses changements de liste de lecture et d'écran répondent à 202 avec status: pending_review et un lien vers la révision, et rien ne change sur un écran tant qu'une personne n'approuve pas. Ses téléversements de médias, ainsi que ses modifications de tags et de dossiers vers des médias approuvés, attendent aussi la révision : les écrans continuent de diffuser ce qui a été approuvé jusqu'à ce qu'une personne approuve le changement, un rejet remet un élément modifié en place, et un téléversement rejeté reste hors des écrans. Il ne peut ni supprimer, ni contrôler les écrans, ni dépenser.

Une session qui tente quelque chose que son niveau ne peut pas faire obtient 403 insufficient_access. Le CLI nomme l’étape suivante : une personne approuve Gérer avec screenrig login --access manage.

Les connexions des agents sont par défaut en Gestion, et les applications connectées en lecture seule. Pour réduire une installation, déconnectez-la, puis reconnectez-vous avec screenrig login --access read ou --access propose. Le niveau d’une session n’est jamais abaissé silencieusement : les paramètres de révision ci-dessous maintiennent les sessions en Proposition sans les modifier, et la page Accès indique quand elles changent.

Capacités

Dans son niveau d’accès, une session fonctionne uniquement dans les zones de capacité que la personne a approuvées : screens, content, playlists, advertising, reports et project. L’inscription accorde les six sur le projet qu’elle crée. Une commande hors des zones approuvées retourne 403 forbidden nommant la capacité manquante. Les capacités restent approuvées pour un projet d’installation ; pour plus, une personne approuve une nouvelle installation qui les possède.

Exiger une révision pour les modifications d’agent

Deux paramètres maintiennent les agents en Proposer sans les reconnecter. Les deux s’appliquent à chaque requête, couvrant ainsi les sessions existantes.

• Exiger une révision pour les modifications des agents, sur la page Paramètres du tableau de bord. Tant que cette option est activée, chaque agent, application connectée et client de service du projet travaille au maximum en mode Proposer : les modifications de ce qui est diffusé attendent dans Révisions qu’une personne les approuve. Le propriétaire du projet ou un administrateur de son organisation peut modifier ce réglage, et le désactiver demande leur clé d’accès. Les révisions déjà en attente restent ouvertes pour décision.
• Peut approuver, pour chaque membre sur la page Accès du projet. Le propriétaire du projet peut toujours approuver. Un membre qui ne peut pas approuver ne décide pas des révisions et ne peut pas donner à un agent la gestion, et les agents dont ce membre est responsable travaillent au maximum en proposition.

Le niveau le plus bas qui s’applique gagne. screenrig agent status rapporte le access de la session, son effective_access et, quand un paramètre l’abaisse, access_limited_by : project ou person. Se reconnecter ne lève pas un paramètre ; le propriétaire du projet le change. Tant qu’un paramètre s’applique, les écrans de connexion et d’approbation de connexion offrent Lecture seule et Proposer, et montrent pourquoi Gérer est indisponible.

Téléverseurs

Un téléverseur travaille dans les listes de lecture et les dossiers de médias que vous choisissez, et nulle part ailleurs. Il téléverse des médias dans ces dossiers et ajoute, remplace et supprime des pages de ces listes de lecture, avec des dates de début et de fin. Il ne peut ni lire ni modifier les autres listes de lecture, écrans, horaires, membres, jetons, liens de flotte, facturation ou paramètres. Une personne de l’équipe d’une agence est un membre téléverseur ; l’agent d’une agence est un client de service téléverseur.

• Inviter ou affecter. Sur la page Accès du tableau de bord, invitez une personne comme téléverseur ou faites d’un membre un téléverseur, puis choisissez les dossiers et les listes de lecture. Depuis la CLI, screenrig invitations create --kind uploader --email designer@example.com --folder-id mfd_FOLDER --playlist-id pl_PLAYLIST en invite un, et screenrig service-client create --name "Agency agent" --uploader --folder-id mfd_FOLDER --playlist-id pl_PLAYLIST --secret-file agency.secret donne à un agent son propre jeton. Les dossiers sont exactement ceux que vous choisissez, pas les dossiers qu’ils contiennent. Le propriétaire modifie le périmètre ou y met fin à tout moment, et le changement s’applique à la prochaine requête du téléverseur.
• Proposer, ou publier sans révision. Les modifications d’un membre téléverseur attendent dans les Révisions que le propriétaire du projet ou un membre pouvant approuver les tranche. Le propriétaire peut laisser un membre publier sans révision (--access manage) lors de l’invitation ou de l’affectation. Un client de service téléverseur agit avec l’accès qu’il a reçu à sa création, Proposer sauf choix contraire, et Exiger une révision pour les modifications d’agent le maintient à Proposer comme tout agent. Un téléverseur n’approuve jamais de révisions et ne connecte jamais d’agents : un agent reçoit plutôt un jeton de téléverseur.
• Téléverser et ajouter des pages. screenrig media upload FILE --folder mfd_FOLDER téléverse dans un dossier du téléverseur. screenrig playlist page add pl_PLAYLIST --media med_IMAGE --from 2026-12-01 --until 2026-12-24 ajoute le média comme page affichée du début du 1er décembre jusqu’à la fin du 24 décembre, dans le fuseau horaire de chaque écran ; playlist page replace remplace le média ou change les dates, et playlist page remove supprime la page. Une page ajoutée par le téléverseur est une image ou une vidéo de ses dossiers ; les autres pages du projet restent telles quelles. Plusieurs ajouts d’affilée d’un même téléverseur rejoignent une même révision, de sorte que le propriétaire les approuve ensemble, et une page qui y attend peut encore être remplacée ou supprimée. La modification d’un autre téléverseur à la liste de lecture attend que cette révision soit décidée.
• Dans le tableau de bord. Un membre téléverseur se connecte à un tableau de bord qui n’a qu’une page, Téléverser, laquelle liste ses listes de lecture et ses dossiers. Dans un dossier, il téléverse des fichiers; sur une liste de lecture, il ajoute une page à partir d’une image ou d’un clip, fixe le premier et le dernier jour d’affichage de la page, remplace ou retire ses propres pages et retire une modification en attente d’examen. Les autres pages du projet indiquent Défini par le projet.
• En dehors du périmètre. Tout le reste répond outside_upload_scope, dont upload_scope énumère les listes de lecture et les dossiers que le téléverseur peut utiliser.

Pour limiter un membre ou un agent à des dossiers d’écrans et à des écrans plutôt qu’au contenu, voir Autorisations par dossier d’écrans.

La page d’accès

La page Accès du tableau de bord liste tout ce qui peut agir sur le projet actuel :

Chaque entrée indique comment l’accès a été obtenu et qui l’a approuvé, son niveau d’accès et ses capacités, ainsi que la date de création et la dernière utilisation. Lorsqu’un paramètre d’examen limite une entrée à un niveau inférieur, l’entrée affiche le niveau auquel elle fonctionne et la raison, par exemple « Proposer — le projet exige une révision ». Déconnecter met fin à un agent ou à une application ; Révoquer met fin à un client de service. Chaque action demande à la personne de confirmer avec sa clé d’accès.

Se déconnecter et révoquer

screenrig logout révoque la connexion sur le serveur, puis supprime les jetons stockés. Si la requête pourrait ne pas avoir atteint le serveur, les jetons restent, donc la relancer est sans risque. Une session en lecture seule peut toujours se déconnecter elle-même.

Une session révoquée ne peut pas se renouveler : aucun nouveau jeton n’est émis après la révocation. Ses jetons d’accès cessent de fonctionner en quelques secondes. Désactiver la personne responsable d’un agent met fin à ses sessions de la même manière, et supprimer un projet met fin à l’accès de toutes les sessions à ce projet.

Durée de la session

Chaque utilisation du jeton d’actualisation prolonge sa validité de 90 jours, jusqu’à un an après la connexion. screenrig doctor indique la fin de session de cette installation, et chaque commande affiche un avertissement dans les 30 derniers jours. Pour continuer, une personne doit approuver un nouveau screenrig login.

Identifiants existants

Les installations connectées avant ces sessions continuent de fonctionner. À la prochaine commande, la CLI intégrée échange la crédential stockée contre une session avec les mêmes projets et capacités, sans invite ni sortie. Mettez à jour le plugin officiel pour obtenir cette CLI; rien d’autre ne change pour l’agent.

Référence

Ces points de terminaison suivent OAuth 2.0. Le CLI intégré, les applications connectées et les clients de service les utilisent ; un agent fonctionnant via le plugin ne les appelle jamais directement.

Les jetons d’accès sont des JWT signés avec Ed25519 (EdDSA) : un profil EdDSA uniquement utilisant les conventions de revendication de la RFC 9068 (typ: at+jwt, iss, aud, sub, client_id, scope, jti, iat, exp). Traitez-les comme opaques : envoyez chacun comme Authorization: Bearer et demandez-en un nouveau à son expiration.

Les erreurs du point de terminaison du jeton sont au format JSON RFC 6749 (error, error_description) avec Cache-Control: no-store :

Les requêtes vers /api avec un jeton d’accès expiré ou révoqué répondent 401 avec WWW-Authenticate: Bearer error="invalid_token" ; le CLI renouvelle une fois et réessaie une fois. Un jeton appelant une action hors de son niveau d’accès répond 403 insufficient_access avec WWW-Authenticate: Bearer error="insufficient_scope" et le scope qui l’autorise.

Les points de terminaison token et revocation acceptent 1 200 requêtes par adresse client par heure, 60 renouvellements par session par heure et 600 jetons service-client par client par heure. Les débuts de connexion sont limités à 10 par adresse par heure.

Lié

• Démarrer : installez le plugin officiel et créez un projet.
• Clients du service : connectez les serveurs, scripts et tâches CI avec les identifiants clients.
• Révisions : approuver, rejeter ou demander des modifications à ce qu’un agent propose.
• Référence CLI : login, logout et les commandes agent.
• Serveur distant : connectez Claude, ChatGPT ou Grok.