Zugriffskontrollen in Ihrer eigenen Integration gestalten

Trennen Sie öffentliche Statusabfragen, eigene Benutzerrechte und geschützte Archivabrufe. Ein Leitfaden für Backend-Plattformteams.

Verantwortungsgrenzen vor dem ersten Aufruf festlegen

Beginnen Sie mit einer klaren Trennung: Reddit Gateway prüft den API-Schlüssel für den geschützten Archivabruf; Ihre Anwendung entscheidet, welcher eigene Benutzer einen solchen Abruf auslösen darf. Daraus entsteht kein vom Archiv bereitgestelltes Rollen- oder Projektberechtigungssystem. Wenn Sie interne Gruppen, Freigaben oder Ausgabenlimits benötigen, müssen Sie diese in Ihrer Plattform umsetzen. Dokumentieren Sie, welche Aktion einen kostenpflichtigen Aufruf auslösen kann und wer darüber entscheidet.

Die öffentliche Route /v1/status eignet sich für eine getrennte Anzeige der HTTP-Erreichbarkeit. Sie benötigt keinen Schlüssel, kostet keine Credits und prüft das Suchsystem nicht. Verwenden Sie ihre Antwort weder zur Freigabe eines Benutzers noch zur Prüfung von Guthaben oder Schlüsseln. Für diese Aufgaben gelten unterschiedliche Abläufe: eigene Zugriffsentscheidung in Ihrer Anwendung, geschützter Datenabruf mit Schlüssel und Kontoverwaltung im angemeldeten Bereich der Seite API-Schlüssel erhalten.

Bewahren Sie den API-Schlüssel auf Ihrem Server auf und vermeiden Sie ihn in Browsercode, Quelltextarchiven, Fehlerseiten und Protokollen. Für den Abruf unterstützen die Endpunkte X-API-Key: <key> und Authorization: Bearer <key>. Die Sitzung im Kontobereich verwendet dagegen eine Secure-HttpOnly-Cookie. Die dort lokal gespeicherten Benutzer- und Rechnungskennungen sind keine Ersatzschlüssel. Diese Trennung erleichtert die Planung; sie ersetzt keine Prüfung Ihrer eigenen Anwendung auf unerwünschte Offenlegung.

Eingaben begrenzen und Antworten prüfen

Ein möglicher eigener Schutz ist eine feste Liste erlaubter API-Pfade und ein fest konfigurierter Host. Ihre Benutzer sollten dann keinen beliebigen Zielhost durchreichen können. Für das konkrete Beispiel verwenden Sie https://api.redditgateway.com/v1/search?q=database&subreddit=backend&limit=3: q sucht nach database, subreddit wählt backend und limit begrenzt die empfangene Seite auf drei Einträge. Dies sind Eingaben für eine historische Suche, keine Zusage bestimmter Treffer. Die Dokumentation erläutert die übrigen Routen und Filter.

Prüfen Sie HTTP-Status und Antwortformat, bevor Ihre Anwendung eine Seite als verarbeitet markiert. Eine leere data-Liste in einer erfolgreichen Antwort ist ein zulässiges Ergebnis; ein Fehler ist nicht dasselbe. Speichern Sie bei Bedarf den tatsächlich empfangenen Inhalt zusammen mit den gewählten Parametern in Ihrer eigenen Verarbeitung. Entscheiden Sie ausdrücklich, welche Daten und Metadaten Ihre Protokolle benötigen, und schließen Sie Schlüssel sowie Authentifizierungs-Header aus diesen Protokollen aus.

Für /v1/search, /v1/posts und /v1/comments stehen die dokumentierten Suchfilter zur Verfügung. from und to verwenden YYYY-MM-DD und beziehen sich auf created_utc; der Endtag wird in UTC vollständig eingeschlossen. min_score filtert, sortiert aber nicht. /v1/item verlangt id und liefert einen einzelnen Datensatz, keinen rekursiven Baum. /v1/subreddits verwendet prefix und limit. Leiten Sie aus vorhandenen parent_id- oder link_id-Feldern keine zusätzlichen serverseitigen Filter ab.

Verbrauch, Fehler und Änderungen handhabbar machen

Begrenzen Sie die eigene Seitenschleife ausdrücklich: page und limit reichen jeweils von 1 bis 100. relation=eq bezeichnet einen exakten Abfragetotalwert, gte eine Untergrenze und unknown einen nicht verlässlichen beziehungsweise fehlenden Gesamtwert. Das sind keine Kennzahlen für die Vollständigkeit des Reddit-Archivs. Bewahren Sie eine empfangene Seite auf, bevor Sie Ihren lokalen Fortschritt verändern. Eine Aufteilung nach Zeiträumen garantiert weder vollständige Erfassung noch überschneidungsfreie oder unveränderliche Ergebnisse.

Ordnen Sie Fehler nach ihrer Ursache ein. Bei 400 sind die Parameter zu korrigieren; bei 401 prüfen Sie Schlüssel und Header. Bei 402 prüfen Sie das Guthaben im Kontobereich und gegebenenfalls die Aufladung. Bei 429 kann Ihre Anwendung begrenzte Wiederholungen mit wachsenden Pausen vorsehen. Das garantiert keinen späteren Erfolg und begründet keine bestimmte Dienstklasse. Die netzwerkweite Kontrolle für Testguthaben ist davon als eigener Mechanismus zu unterscheiden. Die Preisseite erläutert den finanziellen Rahmen.

Kalkulieren Sie erfolgreiche Wiederholungen als neue Abrufe: Auch eine leere erfolgreiche Seite kostet einen Credit. Ungültige Anfragen bleiben ohne Abbuchung; Fehler des vorgeschalteten Suchdienstes führen zur Erstattung der Reservierung. Ein Client-Zeitlimit beweist jedoch nicht, dass der Server keinen kostenpflichtigen Erfolg hatte. Bei einer Schlüsselerneuerung im angemeldeten Kontobereich wird das Passwort verlangt und der bisherige Schlüssel sofort ungültig. Aktualisieren Sie deshalb die betroffenen Serverkonfigurationen bewusst und prüfen Sie danach die geschützte Abfrage.

API-Schlüssel erhalten