Contexte d'exécution

AppKit gère l'authentification Databricks via deux contextes :

• ServiceContext (singleton) : initialisé au démarrage de l'application avec les identifiants du service principal
• ExecutionContext : déterminé au runtime — contexte du service principal ou contexte utilisateur

En-têtes pour le contexte utilisateur

• x-forwarded-user : requis en production ; identifie l'utilisateur
• x-forwarded-access-token : requis pour la transmission du jeton utilisateur

Utiliser asUser(req) pour les opérations à portée utilisateur

Le motif asUser(req) permet aux plugins d'exécuter des opérations avec les identifiants de l'utilisateur à l'origine de la requête :

// Dans un gestionnaire de route d'un plugin personnalisé
router.post("/users/me/data", async (req, res) => {
  // Exécution en tant qu'utilisateur (utilise ses permissions Databricks)
  const result = await this.asUser(req).query("SELECT ...");
  res.json(result);
});

// Exécution via le service principal (par défaut)
router.post("/system/data", async (req, res) => {
  const result = await this.query("SELECT ...");
  res.json(result);
});

Fonctions utilitaires de contexte

Exportées depuis @databricks/appkit :

• getCurrentUserId() : renvoie l'ID de l'utilisateur dans un contexte utilisateur, sinon l'ID du service user
• getWorkspaceClient() : renvoie le WorkspaceClient adapté au contexte courant
• getWarehouseId() : Promise<string> (issu de DATABRICKS_WAREHOUSE_ID ou sélectionné automatiquement en développement)
• getWorkspaceId() : Promise<string> (issu de DATABRICKS_WORKSPACE_ID ou récupéré dynamiquement)

Attributs de span de télémétrie

Le span plugin.execute créé par la chaîne d'intercepteurs d'exécution comporte les attributs suivants :

Ces attributs sont ajoutés automatiquement lorsque votre plugin utilise execute() ou executeStream(). Tous les plugins intégrés utilisent ces méthodes pour leurs opérations OBO. Faites-en de même dans vos plugins personnalisés pour bénéficier d'une instrumentation de télémétrie automatique.

Connexions Lakebase par utilisateur

Le plugin Lakebase utilise un mécanisme différent pour asUser(req) : au lieu de remplacer le WorkspaceClient via AsyncLocalStorage, il crée un pg.Pool distinct par utilisateur, chacun disposant de sa propre actualisation de l'OAuth token. C'est nécessaire car les connexions PostgreSQL sont authentifiées à l'ouverture de la connexion — le pool constitue lui-même la frontière d'authentification.

Consultez Plugin Lakebase — connexions par utilisateur pour plus de détails.

Comportement en mode développement

En développement local (NODE_ENV=development), si asUser(req) est appelé sans jeton utilisateur, un avertissement est consigné et l'usurpation d'identité de l'utilisateur est ignorée : l'opération s'exécute alors avec les identifiants par défaut configurés pour l'application. Le span de télémétrie indiquera execution.context: "service" ainsi que execution.obo_dev_fallback: true, afin de distinguer ces cas des appels classiques effectués par le service principal.