Autorisations

Dropstone utilise la config permission pour décider si une action donnée doit s'exécuter automatiquement, vous demander une approbation, ou être bloquée.

La config booléenne tools héritée est dépréciée ; elle a été fusionnée dans permission. L'ancienne config tools est toujours supportée pour la compatibilité rétroactive.

Actions

Chaque règle de permission se résout en l'une des options suivantes :

• "allow" : exécuter sans approbation
• "ask" : demander une approbation
• "deny" : bloquer l'action

Configuration

Vous pouvez définir les permissions globalement (avec *), et remplacer des outils spécifiques.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

Vous pouvez également définir toutes les permissions à la fois :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": "allow"
}

Règles Granulaires (Syntaxe Objet)

Pour la plupart des permissions, vous pouvez utiliser un objet pour appliquer différentes actions en fonction de l'entrée de l'outil.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "npm *": "allow",
      "rm *": "deny",
      "grep *": "allow"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/content/docs/*.mdx": "allow"
    }
  }
}

Les règles sont évaluées par correspondance de motif, la dernière règle correspondante gagnant. Un motif courant est de placer la règle générique "*" en premier, et les règles plus spécifiques après.

Caractères Génériques

Les motifs de permission utilisent une correspondance de caractères génériques simple :

• * correspond à zéro ou plusieurs caractères quelconques
• ? correspond à exactement un caractère
• Tous les autres caractères correspondent littéralement

Expansion du Répertoire Personnel

Vous pouvez utiliser ~ ou $HOME au début d'un motif pour référencer votre répertoire personnel. Ceci est particulièrement utile pour les règles external_directory.

• ~/projects/* -> /Users/username/projects/*
• $HOME/projects/* -> /Users/username/projects/*
• ~ -> /Users/username

Répertoires Externes

Utilisez external_directory pour autoriser les appels d'outils qui touchent des chemins en dehors du répertoire de travail où Dropstone a été lancé. Ceci s'applique à tout outil qui prend un chemin en entrée (par exemple read, edit, glob, grep, et de nombreuses commandes bash).

L'expansion du répertoire personnel (comme ~/...) affecte uniquement la façon dont un motif est écrit. Elle ne rend pas un chemin externe partie de l'espace de travail actuel, donc les chemins en dehors du répertoire de travail doivent toujours être autorisés via external_directory.

Par exemple, ceci autorise l'accès à tout ce qui se trouve sous ~/projects/personal/ :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    }
  }
}

Tout répertoire autorisé ici hérite des mêmes valeurs par défaut que l'espace de travail actuel. Puisque read est par défaut allow, les lectures sont également autorisées pour les entrées sous external_directory sauf si elles sont remplacées. Ajoutez des règles explicites quand un outil doit être restreint dans ces chemins, comme bloquer les éditions tout en gardant les lectures :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    },
    "edit": {
      "~/projects/personal/**": "deny"
    }
  }
}

Gardez la liste concentrée sur les chemins de confiance, et ajoutez des règles allow ou deny supplémentaires selon les besoins pour d'autres outils (par exemple bash).

Permissions Disponibles

Les permissions Dropstone sont indexées par nom d'outil, plus quelques garde-fous de sécurité :

• read : lire un fichier (correspond au chemin du fichier)
• edit : toutes les modifications de fichier (couvre edit, write, patch)
• glob : globbing de fichiers (correspond au motif glob)
• grep : recherche de contenu (correspond au motif regex)
• bash : exécuter des commandes shell (correspond aux commandes analysées comme git status --porcelain)
• task : lancer des sous-agents (correspond au type de sous-agent)
• skill : charger une compétence (correspond au nom de la compétence)
• lsp : exécuter des requêtes LSP (actuellement non-granulaire)
• question : poser des questions à l'utilisateur pendant l'exécution
• webfetch : récupérer une URL (correspond à l'URL)
• websearch : recherche web (correspond à la requête)
• external_directory : déclenché quand un outil touche des chemins en dehors du répertoire de travail du projet
• doom_loop : déclenché quand le même appel d'outil se répète 3 fois avec une entrée identique

Valeurs Par Défaut

Si vous ne spécifiez rien, Dropstone démarre avec des valeurs par défaut permissives :

• La plupart des permissions sont par défaut "allow".
• doom_loop et external_directory sont par défaut "ask".
• read est "allow", mais les fichiers .env sont bloqués par défaut :

{
  "permission": {
    "read": {
      "*": "allow",
      "*.env": "deny",
      "*.env.*": "deny",
      "*.env.example": "allow"
    }
  }
}

Ce que "Ask" fait

Quand Dropstone demande une approbation, l'interface offre trois résultats :

• once : approuver juste cette requête
• always : approuver les futures requêtes correspondant aux motifs suggérés (pour le reste de la session Dropstone actuelle)
• reject : refuser la requête

L'ensemble des motifs que always approuverait est fourni par l'outil (par exemple, les approbations bash typiquement mettent sur liste blanche un préfixe de commande sûr comme git status*).

Agents

Vous pouvez remplacer les permissions par agent. Les permissions d'agent sont fusionnées avec la config globale, et les règles d'agent ont la priorité. En savoir plus sur les permissions d'agent.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "git commit *": "deny",
      "git push *": "deny",
      "grep *": "allow"
    }
  },
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "*": "ask",
          "git *": "allow",
          "git commit *": "ask",
          "git push *": "deny",
          "grep *": "allow"
        }
      }
    }
  }
}

Vous pouvez également configurer les permissions d'agent en Markdown :

---
description: Révision de code sans éditions
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Analysez uniquement le code et suggérez des modifications.