Python SDK in Frame.io – Authentifizierungsleitfaden
Python SDK in Frame.io – Authentifizierungsleitfaden
In diesem Leitfaden wird erklärt, wie Sie sich mit der Frame.io-API über das Python SDK in Frame.io (frameio) authentifizieren.In der Frame.io V4-API wird der Adobe Identity Management Service (IMS) genutzt, die OAuth-2.0-Identitätsplattform von Adobe.Dies ist eine eigenständige Referenz für Python-Entwickelnde.Alle unten stehenden Codebeispiele und Flüsse gelten ausschließlich für das frameio-Paket.
Authentifizierungstypen im Python SDK
Im Python SDK werden vier Authentifizierungsoptionen unterstützt:
Für Anmeldedaten für Native Apps von Adobe sind selbstdefinierte URI-Schema-Handler erforderlich (z. B. adobe+<hash>://…</hash>), mit denen Weiterleitungen auf Betriebssystemebene abgefangen werden. In Python gibt es keine standardmäßige Möglichkeit, solche Handler zu registrieren. Daher bietet das Python SDK auch keine NativeAppAuth-Klasse an. Nutzen Sie für Python-Apps mit Benutzendeninteraktion WebAppAuth mit einem lokalen Rückrufserver (z. B. Flask oder FastAPI). Verwenden Sie für nicht interaktive Arbeitslasten ServerToServerAuth.
Dienstkonto-User
Bei der Server-zu-Server-Authentifizierung fungiert Ihre Anwendung als Dienstkonto-User, ein spezieller Kontotyp, mit dem im Namen des Services Aktionen durchgeführt werden können.Diese sind für andere Benutzende in Frame.io sichtbar: Wenn eine Aktion von einem Dienstkonto durchgeführt wird, wird dessen Name in der Bedienoberfläche angezeigt.Sie können dem Dienstkonto über die Adobe Admin Console und die Developer Console Zugriff gewähren und diesen widerrufen.Die Namen von Dienstkonten werden über die Frame.io-Bedienoberfläche verwaltet.Standardmäßig heißt Ihre erste S2S-Verbindung Dienstkonto-User, die zweite Dienstkonto-User 2 und so weiter.
Weitere Informationen finden Sie unter Automatisieren Ihres Setups mit der Server-zu-Server-Unterstützung von Frame.io.
Schnellstart
Voraussetzungen
- Anmeldedaten von der Adobe Developer Console:
- Client-ID: Für alle OAuth-Flüsse erforderlich - Clientschlüssel: Für Server-zu-Server- und Web-App-Flüsse erforderlich - Umleitungs-URI: für Web-Anwendungs- und SPA-Flüsse erforderlich; muss in Ihrem Adobe-Projekt registriert sein
- SDK installieren:
Auswählen einer Methode
- **Keine Benutzenden beteiligt?**Verwenden Sie Server-zu-Server (
ServerToServerAuth). - **Benutzende beteiligt und Sie können einen Schlüssel speichern?**Verwenden Sie Web-Anwendung (
WebAppAuth). - **Benutzende beteiligt, aber Sie können keinen Schlüssel speichern?**Verwenden Sie SPA (
SPAAuth).
Zugriffstoken
Falls Sie bereits über einen Zugriffstoken verfügen (aus einem anderen OAuth-System oder von einem vorherigen Austausch, z. B. über unseren API-Explorer), können Sie ihn direkt übergeben:
Dies ist die einfachste Herangehensweise, aber der Token wird letztendlich ablaufen und wird nicht vom SDK aktualisiert.
Ältere Entwicklungstoken
Bei V4-migrierten Konten, die noch nicht über die Adobe Admin Console verwaltet werden, können Sie weiterhin ältere Entwicklungstoken von der Frame.io-Entwickelnden-Website verwenden.Sie müssen den Header x-frameio-legacy-token-auth einbeziehen und auf true setzen:
Ältere Entwicklungstoken laufen nicht ab, sind aber ein Übergangsmechanismus.Für neue Integrationen und Produktionskapazität empfehlen wir die Verwendung einen der unten stehenden OAuth-2.0-Flüsse.Weitere Details finden Sie im Migrationsleitfaden.
Server-zu-Server (Client-Anmeldedaten)
Verwenden Sie dies für Backend-Services und Skripte, die Zugriff auf Frame.io ohne Benutzendeninteraktion benötigen.Dieser Fluss ist nur für Frame.io V4-Konten verfügbar, die über die Adobe Admin Console verwaltet werden.Deine Anwendung wird ohne menschliche Eingriffe als Dienstkonto-User authentifiziert.
Synchron
Asynchron
Das ist alles.auth.get_token ist eine aufrufbare Funktion, die bei jeder Anfrage vom SDK aufgerufen wird.Wenn der aktuelle Token noch gültig ist, wird er sofort zurückgegeben.Wenn er kurz vor dem Ablauf steht, wird zuerst ein neuer Token abgerufen, völlig transparent.
So funktioniert es
Ihre Client-Anmeldedaten (Client-ID und Schlüssel) laufen niemals ab.Sie rotieren sie lediglich manuell, aus Sicherheitsgründen.Durch S2S haben Sie praktisch permanenten, ununterbrochenen API-Zugriff ohne manuelle Eingriffe.
Unter der Haube:
- Beim ersten API-Aufruf wird von
get_tokenmithilfe desclient_credentials-Grants ein neuer Zugriffstoken von Adobe IMS angefordert. - Der Token wird im Arbeitsspeicher zwischengespeichert.Einzelne Zugriffstoken laufen ab (in der Regel nach 24 Stunden), aber das wird für Sie gehandhabt.
- Wenn ein zwischengespeicherter Token innerhalb des Aktualisierungspuffers liegt (Standard: 60 Sekunden vor Ablauf), wird vom SDK mit denselben Client-Anmeldedaten automatisch ein neuer abgerufen.
- Es sind keine Aktualisierungstoken beteiligt.Die Client-Anmeldedaten selbst sind das langlebige Geheimnis, und sie können immer verwendet werden, um einen neuen Zugriffstoken zu prägen.
Explizite Authentifizierung
Wenn Sie den Token frühzeitig abrufen möchten (zum Beispiel, um beim Start schnell mit ungültigen Anmeldedaten zu scheitern):
Web-Anwendung (Autorisierungscode)
Eignet sich für serverseitige Anwendungen, bei denen sich Benutzende mit ihrer Adobe ID anmelden.Für diesen Fluss ist ein Clientschlüssel erforderlich, der sicher auf Ihrem Server gespeichert werden muss.
Rückruf verarbeiten
Wenn Benutzende von Adobe IMS wieder an Ihre redirect-uri zurückgeleitet werden, extrahieren Sie die Parameter code und state. Überprüfen Sie, ob der Status mit dem gespeicherten übereinstimmt, und tauschen Sie dann den Code gegen Token aus:
Synchron
Asynchron
Hiermit wird der Autorisierungscode gegen einen Zugriffstoken und einen Aktualisierungstoken ausgetauscht, und beide werden intern gespeichert.
Vollständiges Flask-Beispiel
Single Page App / PKCE (Autorisierungscode und PKCE)
Dies ist für browserbasierte Anwendungen, Desktop-Anwendungen oder CLI-Tools vorgesehen, in denen ein Clientschlüssel nicht sicher gespeichert werden kann.In dem Fluss wird PKCE (RFC 7636) eingesetzt, um den Austausch des Autorisierungscodes zu schützen.
Autorisierungs-URL generieren
Synchron
Asynchron
Mit get_authorization_url wird ein AuthorizationUrlResult zurückgegeben, das die vollständige URL (mit der eingebetteten PKCE code_challenge) und den code_verifier enthält, den Sie im nächsten Schritt benötigen.
Client verwenden
Synchron
Asynchron
Das ist alles.Aktualisierung funktioniert genauso wie die Web-Anwendung – der Aktualisierungstoken wird automatisch vom SDK verwendet.Der Unterschied besteht darin, dass während der Aktualisierung kein Clientschlüssel gesendet wird, da der SPA-Fluss für öffentliche Clients konzipiert ist.
Asynchrone Verwendung
Zu jeder Autorisierungsklasse gibt es ein asynchrones Gegenstück, dem das Präfix Async vorangestellt ist. Die obigen Codebeispiele enthalten die Registerkarten Sync und Async, wo zutreffend.
Manuelle Aktualisierung der Token
Bei Web-Anwendungs- und SPA-Flüssen werden Token vom SDK automatisch über get_token aktualisiert.Falls Sie explizite Steuerung benötigen, können Sie refresh() direkt aufrufen:
Synchron
Asynchron
Das ist nützlich, wenn Sie vor einem wichtigen Vorgang eine Aktualisierung erzwingen möchten, anstatt sich auf den automatischen Aktualisierungspuffer zu verlassen.
Token-Persistenz
export_tokens() und import_tokens() werden von allen Authentifizierungsklassen unterstützt, um den Tokenstatus auch nach Neustarts aufrechtzuerhalten.Für Web-Anwendungs- und SPA-Flüsse ist das besonders wichtig, da Zugriffs- und Aktualisierungstoken standardmäßig im Arbeitsspeicher gespeichert werden. Wenn Ihre Anwendung neu startet, müssten Benutzende sich erneut authentifizieren, es sei denn, Sie speichern die Token dauerhaft.Bei Server-zu-Server ist die Persistenz optional (es kann immer ein neuer Token mit den Anmeldedaten erstellt werden), doch durch das Importieren eines zwischengespeicherten Tokens wird ein zusätzlicher Umlauf beim Start vermieden.
Exportieren und Importieren
Automatische Persistenz mit on_token_refreshed
Damit Token bei jeder Aktualisierung automatisch dauerhaft gespeichert werden, verwenden Sie den Rückruf on_token_refreshed:
Der Rückruf erhält die gleiche dict-Form wie export_tokens() und wird nach jeder erfolgreichen Tokenaktualisierung ausgelöst. Für die asynchronen Klassen kann on_token_refreshed entweder eine reguläre Funktion oder eine async-Funktion sein.Beide werden unterstützt.
Widerrufen von Token
So melden Sie Benutzende ab und machen deren Token mit Adobe IMS ungültig:
Damit wird sowohl für den Zugriffstoken als auch für den Aktualisierungstoken eine bestmögliche Widerrufsanfrage an Adobe IMS gesendet. Anschließend wird der Status aller lokalen Token gelöscht.Nach dem Widerruf müssen Benutzende sich erneut authentifizieren.
Verwenden Sie bei den asynchronen Klassen await auth.revoke().
Fehlerbehandlung
Alle Authentifizierungsfehler übernehmen von FrameioAuthError, sodass Sie sie allgemein abfangen oder spezifische Fälle behandeln können:
Fehlerreferenz
Umgang mit abgelaufenen Aktualisierungstoken in der Produktion
Bei Web-Anwendungs- und SPA-Flüssen läuft der Aktualisierungstoken irgendwann ab. Wenn das geschieht, wird von get_token ein TokenExpiredError ausgelöst.Diesen sollten Sie abfangen und Benutzende erneut durch den Autorisierungsfluss leiten.
Konfigurationsreferenz
Diese optionalen Parameter werden von allen Authentifizierungsklassen akzeptiert:
Parameterreferenz
Staging-Umgebungen
Zeigen Sie auf eine Staging-Instanz von Adobe IMS, indem Sie ims_base_url überschreiben.Vom SDK wird auch DEFAULT_IMS_BASE_URL (https://ims-na1.adobelogin.com) exportiert, falls Sie den Produktionswert programmgesteuert referenzieren müssen.
Selbstdefinierter HTTP-Client
Für Proxy-Unterstützung oder selbstdefinierte TLS-Konfiguration:
Thread-Sicherheit
Die synchronen Authentifizierungsklassen sind vollkommen Thread-sicher.Wenn get_token von mehreren Threads gleichzeitig aufgerufen wird und eine Aktualisierung erforderlich ist, wird die Aktualisierung nur von einem Thread durchgeführt.Die anderen warten und erhalten das gleiche Ergebnis.Es ist keine externe Sperrung erforderlich.Die asynchronen Klassen bieten mit asyncio.Lock dieselbe Garantie, sicher für gleichzeitige Koroutinen innerhalb einer einzelnen Ereignisschleife.