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.
| Zugangsdaten | Lebensdauer |
|---|---|
| Zugriffstoken | 15 Minuten |
| Aktualisierungstoken | Rotiert 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-Token | 15 Minuten, ohne Aktualisierungstoken: Der Client fordert ein neues an |
Es gibt vier Zugangswege:
| Wer | Wie meldet er sich an | Genehmigt von |
|---|---|---|
| Ein neuer Agent ohne Konto | screenrig agent enroll erstellt Organisation, Screens-Projekt und Sitzung in einem Befehl | Die Registrierung selbst; die per E-Mail versandte Einladung der Person folgt |
| Ein Agent für ein bestehendes Konto | screenrig login druckt einen Code, den eine Person im Dashboard genehmigt | Ein Projektmitglied im Dashboard |
| Eine verbundene App (Claude, ChatGPT, Grok) | Die App öffnet die screenRIG-Zustimmungsseite; siehe Remote-Server | Ein Projektmitglied auf der Zustimmungsseite |
| Ein Server, Skript oder CI-Job | Ein Service-Client meldet sich mit eigenem Schlüssel oder Geheimnis an | Erstellt 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- Der CLI gibt eine Dashboard-Adresse und einen achtstelligen Code wie
BCDF-GHJKaus und wartet dann. - 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. - 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.
- Der CLI speichert die Sitzung, wählt das genehmigte Projekt aus und meldet
status: signed_inmit 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.
| Markieren | Effekt |
|---|---|
--access read, --access propose oder --access manage | Bitten Sie um Nur-Lesen, Vorschlagen oder Verwalten. Standard ist manage; die Person trifft die endgültige Wahl. |
--project prj_ID | Schlagen Sie das Projekt vor, das die Person genehmigt. |
--name NAME | Benennen Sie diese Installation, bis zu 80 Zeichen. |
--no-wait | Gibt sofort mit der Adresse, dem Code und einem login_-Handle zurück. |
--resume login_ID | Warten 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_HANDLEDie 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 manageDie 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 lesen | Vorschlagen | Verwalten | |
|---|---|---|---|
| Bildschirme, Playlists, Medien, Ereignisse und Wiedergaben auflisten und lesen | Ja | Ja | Ja |
| Medien hochladen und bearbeiten, Projektnotizen schreiben, Screenshots aufnehmen, Feedback- und Supportnachrichten senden, Werbekreativen und Kampagnen entwerfen | Nein | Ja | Ja |
| Playlists erstellen und aktualisieren; Bildschirme zuweisen, planen oder übernehmen | Nein | Ja, als Überprüfung genehmigt eine Person | Ja |
| 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 verwalten | Nein | Nein | Ja |
| Guthaben für Einkäufe, Kampagnen oder Bildgenerierung ausgeben | Nein | Nein | Ja |
| Lese Webhook-Empfänger-URLs | Nein: Die URL wird als geschwärzt angezeigt | Nein: Die URL wird als geschwärzt angezeigt | Ja |
| Pro Anfrage abgerechnet wie jede Agent-Anfrage | Ja | Ja | Ja |
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_PLAYLISTeinen ein, undscreenrig service-client create --name "Agency agent" --uploader --folder-id mfd_FOLDER --playlist-id pl_PLAYLIST --secret-file agency.secretgibt 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_FOLDERlädt in einen Ordner des Uploaders hoch.screenrig playlist page add pl_PLAYLIST --media med_IMAGE --from 2026-12-01 --until 2026-12-24fü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 replacetauscht das Medium aus oder ändert die Daten, undplaylist page removeentfernt 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, dessenupload_scopedie 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:
| Abschnitt | Was es auflistet |
|---|---|
| Ausstehend | Anmeldungen und Verbindungsanfragen, die auf Genehmigung warten |
| Personen | Mitglieder und offene Einladungen |
| Agenten | CLI- und Plugin-Installationen, registriert oder angemeldet |
| Verbundene Apps | KI-Assistenten eine angemeldete Person, ein Eintrag pro App |
| Service-Clients | Server, 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 beenden | Ausführen oder tun |
|---|---|
| Die Anmeldung dieser Installation | screenrig logout |
| Der Zugriff dieser Installation auf das aktuelle Projekt | screenrig agent disconnect --yes |
| Diese Installation überall | screenrig agent revoke-identity --yes |
| Jeder Agent oder verbundene App | Trennen auf der Zugriffsseite |
| Ein Service-Client | Widerrufen 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.
| Element | Wert |
|---|---|
| Aussteller | https://api.screenrig.ai |
| Metadaten des Autorisierungsservers | https://api.screenrig.ai/.well-known/oauth-authorization-server |
| Metadaten geschützter Ressourcen | https://api.screenrig.ai/.well-known/oauth-protected-resource/api |
| Token-Endpunkt | https://api.screenrig.ai/oauth/token |
| Geräteautorisierung | https://api.screenrig.ai/oauth/device_authorization |
| Autorisierungs-Endpunkt | https://api.screenrig.ai/oauth/authorize |
| Widerruf | https://api.screenrig.ai/oauth/revoke |
| Grant-Typen | authorization_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-Authentifizierung | none, private_key_jwt (EdDSA, ES256, RS256), client_secret_basic |
| Bereiche | access:read, access:propose, access:manage, identity und die Fähigkeiten screens, content, playlists, advertising, reports und project |
| Ressourcen | https://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:
error | Bedeutung | CLI-Problem |
|---|---|---|
invalid_grant | Die Sitzung wurde widerrufen, ist abgelaufen oder wurde wiederverwendet, oder ein Code ist falsch. | session_ended: Lauf screenrig login |
invalid_client | Unbekannter Client oder falscher Schlüssel, Geheimnis oder Assertion | client_auth_failed |
invalid_scope | Mehr Zugriff oder Fähigkeiten als genehmigt | insufficient_access |
invalid_target | Ein resource außer den beiden oben genannten | invalid_request |
authorization_pending, slow_down | Eine Anmeldung wartet noch auf Genehmigung | Der CLI wartet weiter |
access_denied | Die Person hat die Anmeldung verweigert | login_denied |
expired_token | Der Anmeldecode ist abgelaufen. | login_expired: Lauf screenrig login |
temporarily_unavailable | Versuchen Sie es in Kürze erneut | service_unavailable |
rate_limited | Warten auf Retry-After | rate_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.