Skip to main content
Nutze diese Seite, wenn dein Produkt Anmeldung, sitzungsbasierten Gateway-Zugriff und mehr als eine Chat-Route benötigt. Ziel: Führe die angemeldete Workbench aus und sende Phaseo-Anfragen über einen geschützten serverseitigen Proxy. Ergebnis: Eine lokale Anwendung mit OAuth-Anmeldung, sitzungsgebundenen Tokens, Modellerkennung, Chat und Endpoint-Tester.

Erstelle eine angemeldete Next.js-Workbench mit OAuth und einem einheitlichen Phaseo-Proxy.

In Cursor öffnen

Beispielprojekt

Was die App abdeckt

  • OAuth-2.1- und PKCE-Anmeldung
  • sitzungsgebundene Token-Speicherung und -Erneuerung
  • einen einheitlichen Proxy für Steuerungs- und Generierungsrouten
  • Modellerkennung
  • einen Chat-Ablauf über /responses
  • einen allgemeinen Endpoint-Tester für weitere Gateway-Routen

Wann du mit diesem Beispiel starten solltest

Nutze dieses Beispiel, wenn:
  • Endnutzer sich mit delegiertem Zugriff anmelden sollen
  • du mehr als eine einfache Chat-Seite brauchst
  • du eine sichere Serverroute für mehrere Phaseo-Endpoints möchtest
Starte nicht hier, wenn:
  • du nur eine einfache Chat-UI mit API-Schlüssel brauchst
  • du zuerst ein Skript oder eine CLI möchtest

Wichtige Dateien

  • app/page.tsx
  • app/dashboard/page.tsx
  • app/dashboard/GatewayWorkbench.tsx
  • app/api/gateway/[...surface]/route.ts
  • lib/oauth.ts
  • lib/session.ts

Warum das Beispiel so aufgebaut ist

1. OAuth bleibt von der Gateway-Logik getrennt

Die App trennt:
  • Start- und Callback-Logik der Authentifizierung
  • verschlüsselte Sitzungsverwaltung
  • Token-Erneuerung
Dadurch bleibt der KI-Integrationscode übersichtlich und Anmeldeprobleme lassen sich leichter beheben.

2. Eine Proxy-Route verarbeitet die Gateway-Aufrufe

Die Catch-all-Proxy-Route:
  • prüft die Endpoint-Allowlist
  • fügt das aktuelle Bearer-Token ein
  • erneuert Tokens bei Bedarf
  • leitet Anfrage- und Antwort-Bodies weiter
Das ist ein gutes Muster, wenn du mehrere Phaseo-Endpoints nutzen möchtest, ohne die Authentifizierungslogik in jede Route zu kopieren.

3. Das Dashboard dient zugleich als interne Workbench

Die Workbench-Seite bietet mehr als Chat:
  • sie ermittelt Modelle
  • sie testet /responses
  • sie kann auch Nicht-Chat-Endpoints testen
So eignet sie sich für Onboarding, Qualitätssicherung und interne Fehlerbehebung, bevor du eine ausgefeiltere Nutzeroberfläche entwickelst.

Voraussetzungen

    • Node.js und ein unterstützter Paketmanager
    • ein OAuth-Client mit konfigurierter lokaler Callback-URL
    • ein starkes Sitzungsgeheimnis

Beispiel ausführen

Setze:
  • NEXT_PUBLIC_OAUTH_CLIENT_ID
  • OAUTH_CLIENT_SECRET
  • NEXT_PUBLIC_PHASEO_URL
  • NEXT_PUBLIC_REDIRECT_URI
  • SESSION_SECRET
  • NEXT_PUBLIC_GATEWAY_URL
Starte dann:
Öffne http://localhost:3000.

Ergebnis prüfen

  • Nach der Anmeldung wird die konfigurierte Callback-URL aufgerufen und eine Sitzung erstellt.
  • Das Dashboard kann Modelle über den Proxy ermitteln.
  • Eine Responses-API-Anfrage wird abgeschlossen, ohne ein Zugriffstoken im Browser offenzulegen.
  • Ein Endpoint außerhalb der Proxy-Allowlist wird abgelehnt.

Das Beispiel anpassen

    • kürze die Proxy-Allowlist auf die Endpoints, die dein Produkt wirklich benötigt
    • behalte die Workbench intern und entwickle darauf eine übersichtlichere Nutzeroberfläche
    • ersetze den allgemeinen Tester durch produktspezifische Abläufe, sobald die Integration stabil ist

Verwandte Anleitungen

Zuletzt geändert am 2. Oktober 2026