Documentation

AI Connect/Integration/Modèles Multi-Tenant

Modèles Multi-Tenant

Demandez à l’IA à propos de Vinkius

Un seul client limité à l’application, un contexte résolu avant l’entrée de la requête, des capacités renvoyées uniquement pour l’utilisateur authentifié et une frontière d’isolation que vous pouvez tester.

Un seul client Vinkius dessert tous les utilisateurs de votre application. L'isolation vient de la manière dont vous déduisez l'externalId, et non des instances de client. Cette page est la liste de contrôle de sécurité pour intégrer le SDK dans un backend multi-tenant.

Vinkius ne rencontre jamais vos utilisateurs réels. La plateforme connaît votre Application et l'identifiant opaque transmis par votre backend, rien de plus. E-mails, noms et profils restent dans vos systèmes ; Vinkius ne voit que la portée utilisateur que votre code a résolue.

Créer un seul client limité à l'application

typescript
// 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!,
});

Le client conserve les identifiants de l'application, jamais d'état par utilisateur. Ne créez pas un client par utilisateur ; le contexte utilisateur voyage dans la route.

Résoudre le contexte avant de lire l'entrée de la requête

Liez l'externalId à votre session authentifiée avant toute autre chose. La frontière d'autorisation est votre recherche de session ; un App ID et une clé autorisent l'application, jamais un utilisateur du navigateur :

typescript
async function handleCapabilities(request: Request) {
  const session = await requireSession(request); // your auth code
  const capabilities = await vinkius.user(session.userId).capabilities();
  // ...
}

Renvoyer uniquement les capacités de l'utilisateur authentifié

Projetez les champs dont votre client a besoin et rien d'autre. Les objets de capacité sont déjà limités à l'utilisateur que la session a résolu :

typescript
return Response.json(
  capabilities.map(({ name, description, inputSchema }) => ({
    name,
    description,
    inputSchema,
  })),
);

Autoriser séparément la configuration des connecteurs

Écrire des identifiants est une opération privilégiée. Vérifiez que la session est autorisée à administrer le connecteur de cet utilisateur avant d'appeler connect() et credentials.set() :

typescript
const github = vinkius.user(session.userId).connector('github');
await github.connect();
await github.credentials.set({ GITHUB_TOKEN: submittedToken });

Exécuter uniquement les capacités chargées dans le même contexte

Les capacités transportent la route de connexion qui les a produites. N'acceptez jamais un nom de capacité venant du client pour l'exécuter avec un handle résolu dans un autre contexte ; chargez l'ensemble de capacités dans la requête authentifiée et effectuez le dispatch à partir de celui-ci :

typescript
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 });

Utiliser les métadonnées uniquement pour le contexte applicatif non secret

user.ensure(metadata) crée ou met à jour l'utilisateur et stocke du contexte applicatif tel que le niveau de plan ou des libellés. Ce n'est pas un magasin d'identifiants ; gardez les secrets dans les identifiants de connecteurs, qui sont en écriture seule.

Tester la frontière d'isolation

Deux utilisateurs connectant le même connecteur ne doivent jamais voir l'état l'un de l'autre. Une forme de test minimale :

typescript
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 connection

Exécutez ce test contre un environnement de staging avec son propre App ID et sa propre clé. Consultez Authentication and scope pour les règles de séparation des environnements.

Étapes suivantes