Dokumentation

Agenten mit Zugriff, den Sie kontrollieren anmelden

Jeder Agent, jede App und jedes Skript, das auf Ihren Bildschirmen arbeitet, meldet sich mit eigener Sitzung an. Eine Person genehmigt jede im Dashboard, wählt Nur Lesen, Vorschlagen oder Verwalten und kann sie jederzeit auf der Zugriffsseite beenden.

Wie die Anmeldung funktioniert

screenRIG stellt kurzlebige signierte Zugriffstoken und langlebige Aktualisierungstoken aus. Die gebündelte CLI speichert beide in ihrer privaten Konfigurationsdatei und erneuert sie automatisch, sodass ein Agent niemals ein Token handhabt oder in eine Unterhaltung einfügt.

ZugangsdatenLebensdauer
Zugriffstoken15 Minuten
AktualisierungstokenRotiert bei jeder Nutzung. Es endet 90 Tage nach der letzten Nutzung und spätestens ein Jahr nach der Anmeldung.
Anmeldecode (screenrig login)24 Stunden
Service-Client-Token15 Minuten, ohne Aktualisierungstoken: Der Client fordert ein neues an

Es gibt vier Zugangswege:

WerWie meldet er sich anGenehmigt von
Ein neuer Agent ohne Kontoscreenrig agent enroll erstellt Organisation, Screens-Projekt und Sitzung in einem BefehlDie Registrierung selbst; die per E-Mail versandte Einladung der Person folgt
Ein Agent für ein bestehendes Kontoscreenrig login druckt einen Code, den eine Person im Dashboard genehmigtEin Projektmitglied im Dashboard
Eine verbundene App (Claude, ChatGPT, Grok)Die App öffnet die screenRIG-Zustimmungsseite; siehe Remote-ServerEin Projektmitglied auf der Zustimmungsseite
Ein Server, Skript oder CI-JobEin Service-Client meldet sich mit eigenem Schlüssel oder Geheimnis anErstellt von einem Projektmitglied

Personen melden sich mit einem Passkey oder Passwort oder über den Identitätsanbieter ihrer Organisation im Dashboard an; siehe Single Sign-on und Benutzerbereitstellung.

Anmelden mit screenrig login

Verwenden Sie screenrig login, wenn die Person bereits screenRIG hat und diese Agent-Installation in einem ihrer Projekte funktionieren soll. Eine neue Installation ohne Konto beginnt stattdessen mit screenrig agent enroll; siehe Start.

screenrig login
  1. Der CLI gibt eine Dashboard-Adresse und einen achtstelligen Code wie BCDF-GHJK aus und wartet dann.
  2. Die Person öffnet https://screenrig.ai/dashboard/connect, meldet sich an und gibt den Code ein oder folgt dem vollständigen Link, der ihn bereits enthält.
  3. Das Dashboard zeigt die Anfrage auf einem Bildschirm: den Installationsnamen, den das Gerät gemeldet hat, wann und wo es gefragt hat, und den Code. Die Person prüft, ob der Code zum Terminal passt, passt das Projekt, die Zugriffsebene oder die Fähigkeiten bei Bedarf an und drückt Verbinden. Eine Dashboard-Anmeldung aus der letzten Stunde ist der Beweis, daher fragt Verbinden nichts weiter; eine ältere Anmeldung fragt nach einem Passkey. Das Dashboard öffnet dann den neuen Agenten.
  4. Der CLI speichert die Sitzung, wählt das genehmigte Projekt aus und meldet status: signed_in mit Projekt, Organisation und Zugriffslevel.

Genehmigen Sie nur eine Anmeldung, die Sie selbst auf Ihrem eigenen Computer gestartet haben. Das Dashboard genehmigt beim Laden niemals etwas, und ein abgelaufener Code benötigt einen neuen screenrig login.

MarkierenEffekt
--access read, --access propose oder --access manageBitten Sie um Nur-Lesen, Vorschlagen oder Verwalten. Standard ist manage; die Person trifft die endgültige Wahl.
--project prj_IDSchlagen Sie das Projekt vor, das die Person genehmigt.
--name NAMEBenennen Sie diese Installation, bis zu 80 Zeichen.
--no-waitGibt sofort mit der Adresse, dem Code und einem login_-Handle zurück.
--resume login_IDWarten Sie, bis die ausstehende Anmeldung genehmigt ist, und speichern Sie deren Sitzung.

Wenn der Agent die Adresse zuerst an eine Person in einem anderen Kanal weitergeben muss, verwenden Sie --no-wait. Der Handle enthält kein Geheimnis, und die ausstehende Anmeldung bleibt in der privaten Konfigurationsdatei:

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

Die Anmeldeadresse und ihr Code sind für die Person, die sie genehmigt. Senden Sie sie nur an diese Person und halten Sie sie aus Protokollen und gemeinsamen Kanälen fern.

Projekt hinzufügen oder Zugriff erhöhen

Eine bereits angemeldete Installation führt screenrig login erneut aus, um ein weiteres Projekt hinzuzufügen oder ein Nur-Lesen- oder Vorschlag-Projekt zu einem Manage-Projekt zu erhöhen:

screenrig login --project prj_ID --access manage

Die Person genehmigt diese eine Änderung, und die Installation behält ihre anderen Projekte. screenrig project list zeigt jedes Projekt, das die Installation verwenden kann, und screenrig project use ID wählt eines aus.

Nur lesen, vorschlagen und verwalten

Jede Sitzung trägt eine von drei Zugriffsebenen, die von der Person gewählt wird, die sie genehmigt. Jede Ebene umfasst alles, was die vorherige kann.

Nur lesenVorschlagenVerwalten
Bildschirme, Playlists, Medien, Ereignisse und Wiedergaben auflisten und lesenJaJaJa
Medien hochladen und bearbeiten, Projektnotizen schreiben, Screenshots aufnehmen, Feedback- und Supportnachrichten senden, Werbekreativen und Kampagnen entwerfenNeinJaJa
Playlists erstellen und aktualisieren; Bildschirme zuweisen, planen oder übernehmenNeinJa, als Überprüfung genehmigt eine PersonJa
Löschen, koppeln, archivieren, neu laden, neu starten, Toasts senden, Display-Strom einstellen, Bildschirme taggen, Anwendungs-K/V schreiben, Alarme quittieren, zurückstellen oder stummschalten, Benachrichtigungen und Projekteinstellungen verwaltenNeinNeinJa
Guthaben für Einkäufe, Kampagnen oder Bildgenerierung ausgebenNeinNeinJa
Lese Webhook-Empfänger-URLsNein: Die URL wird als geschwärzt angezeigtNein: Die URL wird als geschwärzt angezeigtJa
Pro Anfrage abgerechnet wie jede Agent-AnfrageJaJaJa

Nur lesen bedeutet, dass die Sitzung nichts ändern oder kaufen kann. Es bedeutet nicht kostenlos: Jede Agenten-Anfrage und jedes abgerechnete Listen-Stream-Ereignis zählt gegen die eingeschlossenen Anfragen der Organisation, wie bei Vorschlag und Verwaltung.

Vorschlagen ermöglicht es einem Agenten, die Arbeit zu erledigen, während eine Person das letzte Wort darüber hat, was abgespielt wird. Änderungen an Playlist und Bildschirm antworten mit 202 auf status: pending_review und einem Link zur Überprüfung, und auf dem Bildschirm ändert sich nichts, bis eine Person zustimmt. Medien-Uploads sowie Tag- und Ordneränderungen zu genehmigten Medien warten ebenfalls auf die Überprüfung: Bildschirme spielen weiterhin das genehmigte Material, bis eine Person die Änderung genehmigt, eine Ablehnung stellt das geänderte Element zurück, und ein abgelehnter Upload bleibt von den Bildschirmen fern. Es kann nicht löschen, Bildschirme steuern oder Ausgaben tätigen.

Eine Sitzung, die etwas versucht, das ihr Level nicht erlaubt, erhält 403 insufficient_access. Die CLI nennt den nächsten Schritt: Eine Person genehmigt Manage mit screenrig login --access manage.

Agentenanmeldungen sind standardmäßig auf Verwalten gesetzt, und verbundene Apps nur auf Lesen. Um eine Installation herabzustufen, trennen Sie sie und melden Sie sich dann erneut mit screenrig login --access read oder --access propose an. Das Niveau einer Sitzung wird niemals stillschweigend herabgestuft: Die untenstehenden Überprüfungseinstellungen halten Sitzungen auf Vorschlagen ohne Änderung, und die Zugriffsseite zeigt an, wenn sie es tun.

Fähigkeiten

Innerhalb seines Zugriffslevels arbeitet eine Sitzung nur in den Fähigkeitsbereichen, die die Person genehmigt hat: screens, content, playlists, advertising, reports und project. Die Anmeldung gewährt alle sechs im Projekt, das sie erstellt. Ein Befehl außerhalb der genehmigten Bereiche gibt 403 forbidden zurück, das die fehlende Fähigkeit benennt. Fähigkeiten bleiben für ein Installationsprojekt genehmigt; für mehr genehmigt eine Person eine neue Installation, die diese besitzt.

Erfordert Überprüfung bei Agentenänderungen

Zwei Einstellungen beschränken Agenten auf Vorschlagszugang, ohne sie erneut anzumelden. Beide gelten bei jeder Anfrage, sodass sie bereits bestehende Sitzungen abdecken.

  • Überprüfung für Agentenänderungen erforderlich, auf der Einstellungen-Seite des Dashboards. Solange dies aktiviert ist, arbeitet jeder Agent, jede verbundene App und jeder Service-Client im Projekt höchstens im Modus Vorschlagen: Änderungen an der Wiedergabe warten in Überprüfungen, bis eine Person sie genehmigt. Der Projektinhaber oder ein Administrator der Organisation ändert dies, und das Deaktivieren erfordert deren Passkey. Bereits wartende Überprüfungen bleiben offen zur Entscheidung.
  • Kann genehmigen, für jedes Mitglied auf der Zugriff-Seite des Projekts. Der Projektinhaber kann immer genehmigen. Ein Mitglied, das nicht genehmigen kann, entscheidet nicht über Reviews und kann einem Agenten keine Verwaltung geben; die Agenten, für die dieses Mitglied verantwortlich ist, arbeiten höchstens mit Vorschlagsrechten.

Die niedrigste anwendbare Ebene gewinnt. screenrig agent status meldet die Sitzung access, deren effective_access und, wenn eine Einstellung sie senkt, access_limited_by: project oder person. Ein erneutes Anmelden hebt eine Einstellung nicht auf; der Projekteigentümer ändert sie. Solange eine Einstellung gilt, bieten die Anmelde- und Verbindungsfreigabebildschirme Nur lesen und Vorschlagen an und zeigen, warum Verwalten nicht verfügbar ist.

Uploader

Ein Uploader arbeitet in den Playlists und Medienordnern, die Sie auswählen, und nirgendwo sonst. Er lädt Medien in diese Ordner hoch und fügt Seiten dieser Playlists hinzu, ersetzt und entfernt sie, mit Start- und Enddatum. Er kann keine anderen Playlists, Bildschirme, Zeitpläne, Mitglieder, Tokens, Flottenverknüpfungen, Abrechnung oder Einstellungen lesen oder ändern. Eine Person im Team einer Agentur ist ein Uploader-Mitglied; der Agent einer Agentur ist ein Uploader-Service-Client.

  • Einladen oder zuweisen. Laden Sie auf der Zugriffsseite des Dashboards eine Person als Uploader ein oder machen Sie ein Mitglied zum Uploader, und wählen Sie die Ordner und Playlists aus. Über die CLI lädt screenrig invitations create --kind uploader --email designer@example.com --folder-id mfd_FOLDER --playlist-id pl_PLAYLIST einen ein, und screenrig service-client create --name "Agency agent" --uploader --folder-id mfd_FOLDER --playlist-id pl_PLAYLIST --secret-file agency.secret gibt einem Agenten ein eigenes Token. Die Ordner sind genau die, die Sie auswählen, nicht die darin enthaltenen Ordner. Der Eigentümer ändert den Bereich oder beendet ihn jederzeit, und die Änderung gilt für die nächste Anfrage des Uploaders.
  • Vorschlagen oder ohne Überprüfung veröffentlichen. Änderungen eines Uploader-Mitglieds warten in den Überprüfungen, bis der Projekteigentümer oder ein Mitglied mit Genehmigungsrecht darüber entscheidet. Der Eigentümer kann ein Mitglied beim Einladen oder Zuweisen ohne Überprüfung veröffentlichen lassen (--access manage). Ein Uploader-Service-Client handelt mit dem Zugriff, mit dem er erstellt wurde, standardmäßig Vorschlagen, und Erfordert Überprüfung bei Agentenänderungen hält ihn wie jeden Agenten bei Vorschlagen. Ein Uploader genehmigt nie Überprüfungen und verbindet nie Agenten: Ein Agent erhält stattdessen ein Uploader-Token.
  • Hochladen und Seiten hinzufügen. screenrig media upload FILE --folder mfd_FOLDER lädt in einen Ordner des Uploaders hoch. screenrig playlist page add pl_PLAYLIST --media med_IMAGE --from 2026-12-01 --until 2026-12-24 fügt das Medium als Seite hinzu, die vom Beginn des 1. Dezember bis zum Ende des 24. Dezember angezeigt wird, in der Zeitzone jedes Bildschirms; playlist page replace tauscht das Medium aus oder ändert die Daten, und playlist page remove entfernt die Seite. Eine vom Uploader hinzugefügte Seite ist ein Bild oder Video aus seinen Ordnern; die übrigen Seiten des Projekts bleiben unverändert. Mehrere Uploads hintereinander desselben Uploaders werden einer Überprüfung zugeordnet, sodass der Eigentümer sie gemeinsam genehmigt; eine Seite, die darin noch wartet, kann ersetzt oder entfernt werden. Die Änderung eines anderen Uploaders an der Playlist wartet, bis diese Überprüfung entschieden ist.
  • Im Dashboard. Ein Mitglied, das Uploader ist, meldet sich an einem Dashboard mit nur einer Seite an, Hochladen, die seine Playlists und Ordner auflistet. In einem Ordner lädt es Dateien hoch; in einer Playlist fügt es eine Seite aus einem Bild oder einem Clip hinzu, legt den ersten und den letzten Tag fest, an dem die Seite erscheint, ersetzt oder entfernt seine eigenen Seiten und zieht eine Änderung zurück, die auf Prüfung wartet. Die übrigen Seiten des Projekts zeigen Vom Projekt festgelegt.
  • Außerhalb des Bereichs. Alles andere antwortet mit outside_upload_scope, dessen upload_scope die Playlists und Ordner auflistet, die der Uploader verwenden darf.

Um ein Mitglied oder einen Agenten auf Bildschirmordner und Bildschirme statt auf Inhalte zu beschränken, siehe Berechtigungen nach Bildschirmordner.

Die Zugangsseite

Die Zugriffs-Seite des Dashboards listet alles auf, was im aktuellen Projekt agieren kann:

AbschnittWas es auflistet
AusstehendAnmeldungen und Verbindungsanfragen, die auf Genehmigung warten
PersonenMitglieder und offene Einladungen
AgentenCLI- und Plugin-Installationen, registriert oder angemeldet
Verbundene AppsKI-Assistenten eine angemeldete Person, ein Eintrag pro App
Service-ClientsServer, Skripte und CI-Jobs mit ihren Schlüsseln und Geheimnissen

Jeder Eintrag zeigt, wie er Zugriff erhalten hat und wer ihn genehmigt hat, seine Zugriffsebene und Fähigkeiten sowie wann er erstellt und zuletzt verwendet wurde. Wenn eine Überprüfungseinstellung einen Eintrag unter seiner Ebene hält, zeigt der Eintrag die Ebene, auf der er arbeitet, und warum, z. B. "Vorschlagen — Projekt erfordert Überprüfung". Trennen beendet einen Agenten oder eine App; Widerrufen beendet einen Service-Client. Jeder fordert die Person auf, mit ihrem Passkey zu bestätigen.

Abmelden und widerrufen

Um zu beendenAusführen oder tun
Die Anmeldung dieser Installationscreenrig logout
Der Zugriff dieser Installation auf das aktuelle Projektscreenrig agent disconnect --yes
Diese Installation überallscreenrig agent revoke-identity --yes
Jeder Agent oder verbundene AppTrennen auf der Zugriffsseite
Ein Service-ClientWiderrufen auf der Zugriffsseite oder screenrig service-client revoke ID --yes

screenrig logout widerruft die Anmeldung auf dem Server und entfernt dann die gespeicherten Tokens. Wenn die Anfrage den Server möglicherweise nicht erreicht hat, bleiben die Tokens erhalten, sodass ein erneutes Ausführen sicher ist. Eine Nur-Lesen-Sitzung kann sich immer selbst trennen.

Eine widerrufene Sitzung kann kein neues Token erhalten: Nach dem Widerruf wird kein neues Token ausgegeben. Ihre Zugriffstoken funktionieren innerhalb von Sekunden nicht mehr. Die Deaktivierung der verantwortlichen Person eines Agenten beendet dessen Sitzungen auf dieselbe Weise, und das Löschen eines Projekts beendet den Zugriff aller Sitzungen auf dieses Projekt.

Sitzungsdauer

Jede Verwendung des Refresh-Tokens verschiebt sein Ende um 90 Tage nach vorne, bis zu einem Jahr nach der Anmeldung. screenrig doctor zeigt, wann die Sitzung dieser Installation endet, und jeder Befehl warnt in den letzten 30 Tagen. Um fortzufahren, genehmigt eine Person einen neuen screenrig login.

Vorhandene Anmeldedaten

Installationen, die sich vor diesen Sitzungen angemeldet haben, funktionieren weiterhin. Beim nächsten Befehl tauscht die enthaltene CLI die gespeicherte Anmeldeinformation gegen eine Sitzung mit denselben Projekten und Berechtigungen aus, ohne Eingabeaufforderung und ohne Ausgabe. Aktualisieren Sie das offizielle Plugin, um diese CLI zu erhalten; für den Agenten ändert sich sonst nichts.

Referenz

Diese Endpunkte folgen OAuth 2.0. Die gebündelte CLI, verbundene Apps und Service-Clients verwenden sie; ein Agent, der über das Plugin arbeitet, ruft sie niemals direkt auf.

ElementWert
Ausstellerhttps://api.screenrig.ai
Metadaten des Autorisierungsservershttps://api.screenrig.ai/.well-known/oauth-authorization-server
Metadaten geschützter Ressourcenhttps://api.screenrig.ai/.well-known/oauth-protected-resource/api
Token-Endpunkthttps://api.screenrig.ai/oauth/token
Geräteautorisierunghttps://api.screenrig.ai/oauth/device_authorization
Autorisierungs-Endpunkthttps://api.screenrig.ai/oauth/authorize
Widerrufhttps://api.screenrig.ai/oauth/revoke
Grant-Typenauthorization_code (nur PKCE S256), refresh_token, urn:ietf:params:oauth:grant-type:device_code, client_credentials, urn:ietf:params:oauth:grant-type:token-exchange
Client-Authentifizierungnone, private_key_jwt (EdDSA, ES256, RS256), client_secret_basic
Bereicheaccess:read, access:propose, access:manage, identity und die Fähigkeiten screens, content, playlists, advertising, reports und project
Ressourcenhttps://api.screenrig.ai/api (Standard) und https://api.screenrig.ai/mcp

Zugriffstoken sind JWTs, die mit Ed25519 (EdDSA) signiert sind: ein EdDSA-only-Profil, das die Anspruchskonventionen von RFC 9068 (typ: at+jwt, iss, aud, sub, client_id, scope, jti, iat, exp) verwendet. Behandeln Sie sie als undurchsichtig: Senden Sie jedes als Authorization: Bearer und fordern Sie ein neues an, wenn es abläuft.

Fehler am Token-Endpunkt sind RFC 6749 JSON (error, error_description) mit Cache-Control: no-store:

errorBedeutungCLI-Problem
invalid_grantDie Sitzung wurde widerrufen, ist abgelaufen oder wurde wiederverwendet, oder ein Code ist falsch.session_ended: Lauf screenrig login
invalid_clientUnbekannter Client oder falscher Schlüssel, Geheimnis oder Assertionclient_auth_failed
invalid_scopeMehr Zugriff oder Fähigkeiten als genehmigtinsufficient_access
invalid_targetEin resource außer den beiden oben genannteninvalid_request
authorization_pending, slow_downEine Anmeldung wartet noch auf GenehmigungDer CLI wartet weiter
access_deniedDie Person hat die Anmeldung verweigertlogin_denied
expired_tokenDer Anmeldecode ist abgelaufen.login_expired: Lauf screenrig login
temporarily_unavailableVersuchen Sie es in Kürze erneutservice_unavailable
rate_limitedWarten auf Retry-Afterrate_limited

Anfragen an /api mit abgelaufenem oder widerrufenem Zugriffstoken antworten mit 401 und WWW-Authenticate: Bearer error="invalid_token"; die CLI erneuert einmal und versucht es erneut. Ein Token, das eine Aktion aufruft, die sein Zugriffsniveau nicht erlaubt, antwortet mit 403 insufficient_access und WWW-Authenticate: Bearer error="insufficient_scope" sowie dem scope, das es erlaubt.

Die Token- und Widerrufsendpunkte akzeptieren 1.200 Anfragen pro Client-Adresse pro Stunde, 60 Erneuerungen pro Sitzung pro Stunde und 600 Service-Client-Token pro Client pro Stunde. Anmeldeversuche sind auf 10 pro Adresse pro Stunde begrenzt.