AI Connect/Integration/Multi-Tenant-Muster
Multi-Tenant-Muster
Ein einziger Client mit Anwendungsgültigkeit, Gültigkeitsbereich vor der Anfrageeingabe aufgelöst, Capabilities nur für den authentifizierten Benutzer zurückgegeben und eine Isolationsgrenze, die Sie testen können.
Ein einziger Vinkius-Client bedient alle Benutzer Ihrer Anwendung. Die Isolation ergibt sich daraus, wie Sie externalId ableiten, nicht aus Client-Instanzen. Diese Seite ist die Sicherheits-Checkliste für die Anbindung des SDK an ein Multi-Tenant-Backend.
Vinkius trifft Ihre echten Nutzer niemals. Die Plattform kennt Ihre Application und den opaken Bezeichner, den Ihr Backend übergibt, und nichts weiter. E-Mails, Namen und Profile bleiben in Ihren Systemen; Vinkius sieht nur den Benutzerbereich, den Ihr Code aufgelöst hat.
Einen einzigen Client mit Anwendungsgültigkeit erstellen
// lib/vinkius.ts — server only
import { Vinkius } from '@vinkius/connect';
export const vinkius = new Vinkius({
appId: process.env.VINKIUS_APP_ID!,
apiKey: process.env.VINKIUS_APP_KEY!,
});Der Client enthält Anmeldeinformationen der Anwendung, niemals benutzerbezogenen Zustand. Erstellen Sie nicht einen Client pro Benutzer; der Benutzerbereich wird in der Route übertragen.
Gültigkeitsbereich vor dem Lesen der Anfrageeingabe auflösen
Binden Sie externalId zuerst an Ihre authentifizierte Sitzung. Die Autorisierungsgrenze ist Ihre Sitzungssuche; eine App-ID und ein Schlüssel autorisieren die Anwendung, niemals einen Browserbenutzer:
async function handleCapabilities(request: Request) {
const session = await requireSession(request); // your auth code
const capabilities = await vinkius.user(session.userId).capabilities();
// ...
}Nur die Capabilities des authentifizierten Benutzers zurückgeben
Projizieren Sie genau die Felder, die Ihr Client benötigt, und nichts anderes. Die Capability-Objekte sind bereits auf den Benutzer beschränkt, den die Sitzung aufgelöst hat:
return Response.json(
capabilities.map(({ name, description, inputSchema }) => ({
name,
description,
inputSchema,
})),
);Die Connector-Einrichtung separat autorisieren
Das Schreiben von Anmeldeinformationen ist ein privilegierter Vorgang. Prüfen Sie, ob die Sitzung den Connector dieses Benutzers verwalten darf, bevor Sie connect() und credentials.set() aufrufen:
const github = vinkius.user(session.userId).connector('github');
await github.connect();
await github.credentials.set({ GITHUB_TOKEN: submittedToken });Nur im selben Gültigkeitsbereich geladene Capabilities ausführen
Capabilities tragen die Verbindungsroute, die sie erzeugt hat. Akzeptieren Sie niemals einen Capability-Namen vom Client und führen Sie ihn mit einem Handle aus einem anderen Gültigkeitsbereich aus; laden Sie den Capability-Satz innerhalb der authentifizierten Anfrage und dispatchen Sie davon:
const capabilities = await vinkius.user(session.userId).capabilities();
const capability = capabilities.findCapability(requestedName);
if (!capability) {
return Response.json({ error: 'not available for this user' }, { status: 404 });
}
const result = await capability.execute(args, { idempotencyKey });Metadaten nur für nicht geheimen Anwendungskontext verwenden
user.ensure(metadata) führt einen Upsert des Benutzers durch und speichert Anwendungskontext wie Planstufe oder Labels. Es ist kein Speicher für Anmeldeinformationen; bewahren Sie Geheimnisse in Connector-Anmeldeinformationen auf, die nur schreibbar sind.
Die Isolationsgrenze testen
Zwei Benutzer, die denselben Connector verbinden, dürfen den Zustand des anderen niemals sehen. Ein minimales Testgerüst:
const alice = vinkius.user('alice_123');
const bob = vinkius.user('bob_456');
await alice.connector('github').connect();
const bobConnectors = await bob.connectors();
// bob's list must not contain alice's connectionFühren Sie diesen Test gegen eine Staging-Umgebung mit eigener App-ID und eigenem Schlüssel aus. Siehe Authentication and scope für die Regeln zur Umgebungstrennung.
