chore(i18n): refresh fr translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
2bf8326873
commit
f87f4538b3
@ -1,43 +1,43 @@
|
||||
---
|
||||
read_when:
|
||||
- Configuration du contrôle d’accès aux messages directs
|
||||
- Appairage d’un nouveau Node iOS/Android
|
||||
- Association d’un nouveau Node iOS/Android
|
||||
- Examen de la posture de sécurité d’OpenClaw
|
||||
summary: 'Vue d’ensemble de l’appairage : approuver qui peut vous envoyer des messages privés + quels nœuds peuvent rejoindre'
|
||||
summary: 'Aperçu de l’appairage : approuver qui peut vous envoyer des messages privés + quels nœuds peuvent rejoindre'
|
||||
title: Appairage
|
||||
x-i18n:
|
||||
generated_at: "2026-05-04T02:21:51Z"
|
||||
generated_at: "2026-05-04T07:21:44Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 4fb27840f7c9ef55e7270cc29f813e6db90b240aa2180f30952eb9485f0f8874
|
||||
source_hash: f2bce4cfba7708b0003f2ffeacada8bc1849cc301f28178b499a9a67bddcf36d
|
||||
source_path: channels/pairing.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
« L’appairage » est l’étape d’approbation explicite d’accès d’OpenClaw.
|
||||
Il est utilisé à deux endroits :
|
||||
« Appairage » est l’étape d’approbation explicite d’accès d’OpenClaw.
|
||||
Elle est utilisée à deux endroits :
|
||||
|
||||
1. **Appairage DM** (qui est autorisé à parler au bot)
|
||||
2. **Appairage Node** (quels appareils/nœuds sont autorisés à rejoindre le réseau du Gateway)
|
||||
2. **Appairage Node** (quels appareils/nœuds sont autorisés à rejoindre le réseau Gateway)
|
||||
|
||||
Contexte de sécurité : [Sécurité](/fr/gateway/security)
|
||||
|
||||
## 1) Appairage DM (accès par chat entrant)
|
||||
## 1) Appairage DM (accès au chat entrant)
|
||||
|
||||
Lorsqu’un canal est configuré avec la politique DM `pairing`, les expéditeurs inconnus reçoivent un code court et leur message n’est **pas traité** tant que vous ne l’avez pas approuvé.
|
||||
|
||||
Les politiques DM par défaut sont documentées dans : [Sécurité](/fr/gateway/security)
|
||||
|
||||
`dmPolicy: "open"` n’est public que lorsque la liste d’autorisation DM effective inclut `"*"`.
|
||||
La configuration et la validation exigent ce joker pour les configurations publiques ouvertes. Si l’état existant
|
||||
contient `open` avec des entrées `allowFrom` concrètes, le runtime n’admet toujours
|
||||
La configuration et la validation exigent ce joker pour les configurations public-open. Si l’état existant
|
||||
contient `open` avec des entrées `allowFrom` concrètes, l’exécution n’admet toujours
|
||||
que ces expéditeurs, et les approbations du magasin d’appairage n’élargissent pas l’accès `open`.
|
||||
|
||||
Codes d’appairage :
|
||||
|
||||
- 8 caractères, majuscules, sans caractères ambigus (`0O1I`).
|
||||
- **Expirent après 1 heure**. Le bot n’envoie le message d’appairage que lorsqu’une nouvelle demande est créée (environ une fois par heure et par expéditeur).
|
||||
- Les demandes d’appairage DM en attente sont plafonnées à **3 par canal** par défaut ; les demandes supplémentaires sont ignorées jusqu’à ce qu’une demande expire ou soit approuvée.
|
||||
- Les demandes d’appairage DM en attente sont limitées à **3 par canal** par défaut ; les demandes supplémentaires sont ignorées jusqu’à ce qu’une demande expire ou soit approuvée.
|
||||
|
||||
### Approuver un expéditeur
|
||||
|
||||
@ -49,8 +49,8 @@ openclaw pairing approve telegram <CODE>
|
||||
Si aucun propriétaire de commande n’est encore configuré, l’approbation d’un code d’appairage DM initialise aussi
|
||||
`commands.ownerAllowFrom` avec l’expéditeur approuvé, par exemple `telegram:123456789`.
|
||||
Cela donne aux premières configurations un propriétaire explicite pour les commandes privilégiées et les invites
|
||||
d’approbation d’exécution. Une fois qu’un propriétaire existe, les approbations d’appairage ultérieures accordent seulement l’accès DM ;
|
||||
elles n’ajoutent pas d’autres propriétaires.
|
||||
d’approbation d’exécution. Une fois qu’un propriétaire existe, les approbations d’appairage ultérieures accordent uniquement
|
||||
l’accès DM ; elles n’ajoutent pas d’autres propriétaires.
|
||||
|
||||
Canaux pris en charge : `bluebubbles`, `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`.
|
||||
|
||||
@ -60,7 +60,7 @@ Utilisez `accessGroups` au niveau supérieur lorsque le même ensemble d’expé
|
||||
plusieurs canaux de messagerie ou à la fois aux listes d’autorisation DM et de groupe.
|
||||
|
||||
Les groupes statiques utilisent `type: "message.senders"` et sont référencés avec
|
||||
`accessGroup:<name>` depuis les listes d’autorisation de canal :
|
||||
`accessGroup:<name>` depuis les listes d’autorisation des canaux :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -88,59 +88,65 @@ Les groupes d’accès sont documentés en détail ici : [Groupes d’accès](/f
|
||||
Stocké sous `~/.openclaw/credentials/` :
|
||||
|
||||
- Demandes en attente : `<channel>-pairing.json`
|
||||
- Magasin de liste d’autorisation approuvée :
|
||||
- Magasin de liste d’autorisation approuvé :
|
||||
- Compte par défaut : `<channel>-allowFrom.json`
|
||||
- Compte non par défaut : `<channel>-<accountId>-allowFrom.json`
|
||||
|
||||
Comportement de portée par compte :
|
||||
Comportement de portée des comptes :
|
||||
|
||||
- Les comptes non par défaut lisent/écrivent uniquement leur fichier de liste d’autorisation à portée définie.
|
||||
- Le compte par défaut utilise le fichier de liste d’autorisation non limité à un compte, à portée du canal.
|
||||
- Les comptes non par défaut lisent/écrivent uniquement leur fichier de liste d’autorisation scoped.
|
||||
- Le compte par défaut utilise le fichier de liste d’autorisation non scoped du canal.
|
||||
|
||||
Traitez ces fichiers comme sensibles (ils contrôlent l’accès à votre assistant).
|
||||
|
||||
<Note>
|
||||
Le magasin de liste d’autorisation d’appairage sert à l’accès DM. L’autorisation de groupe est distincte.
|
||||
Approuver un code d’appairage DM n’autorise pas automatiquement cet expéditeur à exécuter des commandes de groupe
|
||||
ou à contrôler le bot dans les groupes. L’initialisation du premier propriétaire est un état de configuration séparé
|
||||
dans `commands.ownerAllowFrom`, et la livraison de chat de groupe suit toujours les listes d’autorisation de groupe
|
||||
du canal (par exemple `groupAllowFrom`, `groups`, ou des substitutions par groupe
|
||||
Le magasin de liste d’autorisation d’appairage concerne l’accès DM. L’autorisation de groupe est séparée.
|
||||
L’approbation d’un code d’appairage DM n’autorise pas automatiquement cet expéditeur à exécuter des commandes
|
||||
de groupe ni à contrôler le bot dans des groupes. L’initialisation du premier propriétaire est un état de configuration
|
||||
séparé dans `commands.ownerAllowFrom`, et la livraison dans les discussions de groupe suit toujours les
|
||||
listes d’autorisation de groupe du canal (par exemple `groupAllowFrom`, `groups`, ou des remplacements par groupe
|
||||
ou par sujet selon le canal).
|
||||
</Note>
|
||||
|
||||
## 2) Appairage d’appareils Node (nœuds iOS/Android/macOS/headless)
|
||||
## 2) Appairage d’appareil Node (nœuds iOS/Android/macOS/headless)
|
||||
|
||||
Les nœuds se connectent au Gateway comme **appareils** avec `role: node`. Le Gateway
|
||||
Les nœuds se connectent au Gateway comme des **appareils** avec `role: node`. Le Gateway
|
||||
crée une demande d’appairage d’appareil qui doit être approuvée.
|
||||
|
||||
### Appairer via Telegram (recommandé pour iOS)
|
||||
|
||||
Si vous utilisez le plugin `device-pair`, vous pouvez effectuer le premier appairage d’appareil entièrement depuis Telegram :
|
||||
Si vous utilisez le Plugin `device-pair`, vous pouvez effectuer le premier appairage d’appareil entièrement depuis Telegram :
|
||||
|
||||
1. Dans Telegram, envoyez un message à votre bot : `/pair`
|
||||
2. Le bot répond avec deux messages : un message d’instructions et un message séparé de **code de configuration** (facile à copier/coller dans Telegram).
|
||||
3. Sur votre téléphone, ouvrez l’application iOS OpenClaw → Settings → Gateway.
|
||||
4. Collez le code de configuration et connectez-vous.
|
||||
5. De retour dans Telegram : `/pair pending` (examinez les ID de demande, le rôle et les portées), puis approuvez.
|
||||
2. Le bot répond avec deux messages : un message d’instructions et un message séparé contenant un **code de configuration** (facile à copier/coller dans Telegram).
|
||||
3. Sur votre téléphone, ouvrez l’app OpenClaw iOS → Settings → Gateway.
|
||||
4. Scannez le code QR ou collez le code de configuration, puis connectez-vous.
|
||||
5. De retour dans Telegram : `/pair pending` (examiner les ID de demande, le rôle et les portées), puis approuvez.
|
||||
|
||||
Le code de configuration est une charge utile JSON encodée en base64 qui contient :
|
||||
|
||||
- `url` : l’URL WebSocket du Gateway (`ws://...` ou `wss://...`)
|
||||
- `bootstrapToken` : un jeton d’amorçage éphémère à appareil unique utilisé pour la poignée de main d’appairage initiale
|
||||
- `bootstrapToken` : un jeton bootstrap de courte durée pour un seul appareil, utilisé pour la poignée de main d’appairage initiale
|
||||
|
||||
Ce jeton d’amorçage porte le profil d’amorçage d’appairage intégré :
|
||||
Ce jeton bootstrap porte le profil bootstrap d’appairage intégré :
|
||||
|
||||
- le jeton `node` principal transmis reste `scopes: []`
|
||||
- tout jeton `operator` transmis reste limité à la liste d’autorisation d’amorçage :
|
||||
- tout jeton `operator` transmis reste limité à la liste d’autorisation bootstrap :
|
||||
`operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write`
|
||||
- les vérifications de portée d’amorçage sont préfixées par rôle, et non un seul ensemble plat de portées :
|
||||
les entrées de portée operator satisfont seulement les demandes operator, et les rôles non operator
|
||||
- les vérifications de portée bootstrap sont préfixées par rôle, et non regroupées dans un seul ensemble de portées plat :
|
||||
les entrées de portée operator ne satisfont que les demandes operator, et les rôles non-operator
|
||||
doivent toujours demander des portées sous leur propre préfixe de rôle
|
||||
- la rotation/révocation ultérieure des jetons reste limitée à la fois par le contrat de rôle approuvé de l’appareil
|
||||
et par les portées operator de la session appelante
|
||||
|
||||
Traitez le code de configuration comme un mot de passe tant qu’il est valide.
|
||||
|
||||
Pour Tailscale, les configurations publiques ou tout autre appairage mobile non-loopback, utilisez Tailscale
|
||||
Serve/Funnel ou une autre URL Gateway `wss://`. Les URL de configuration `ws://` directes non-loopback
|
||||
sont rejetées avant l’émission du QR/code de configuration. Les codes de configuration `ws://` en texte clair
|
||||
sont limités aux URL loopback ; les clients `ws://` de réseau privé exigent toujours le break-glass explicite
|
||||
`OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` décrit dans le guide du Gateway distant.
|
||||
|
||||
### Approuver un appareil Node
|
||||
|
||||
```bash
|
||||
@ -149,25 +155,24 @@ openclaw devices approve <requestId>
|
||||
openclaw devices reject <requestId>
|
||||
```
|
||||
|
||||
Lorsqu’une approbation explicite est refusée parce que la session d’appareil appairé approbatrice
|
||||
Lorsqu’une approbation explicite est refusée parce que la session d’appareil appairé qui l’approuve
|
||||
a été ouverte avec une portée limitée à l’appairage, la CLI réessaie la même demande avec
|
||||
`operator.admin`. Cela permet à un appareil appairé existant disposant des capacités d’administration de récupérer un nouvel
|
||||
`operator.admin`. Cela permet à un appareil appairé disposant déjà de capacités admin de récupérer un nouvel
|
||||
appairage Control UI/navigateur sans modifier `devices/paired.json` à la main. Le
|
||||
Gateway valide toujours la connexion retentée ; les jetons qui ne peuvent pas s’authentifier
|
||||
Gateway valide toujours la connexion réessayée ; les jetons qui ne peuvent pas s’authentifier
|
||||
avec `operator.admin` restent bloqués.
|
||||
|
||||
Si le même appareil réessaie avec des détails d’authentification différents (par exemple un
|
||||
rôle/des portées/une clé publique différents), la demande en attente précédente est remplacée et un nouveau
|
||||
Si le même appareil réessaie avec des détails d’authentification différents (par exemple un rôle, des portées ou une clé publique différents), la demande en attente précédente est remplacée et un nouveau
|
||||
`requestId` est créé.
|
||||
|
||||
<Note>
|
||||
Un appareil déjà appairé n’obtient pas silencieusement un accès plus large. S’il se reconnecte en demandant plus de portées ou un rôle plus large, OpenClaw conserve l’approbation existante telle quelle et crée une nouvelle demande de mise à niveau en attente. Utilisez `openclaw devices list` pour comparer l’accès actuellement approuvé avec l’accès nouvellement demandé avant d’approuver.
|
||||
Un appareil déjà appairé n’obtient pas silencieusement un accès plus large. S’il se reconnecte en demandant davantage de portées ou un rôle plus large, OpenClaw conserve l’approbation existante telle quelle et crée une nouvelle demande de mise à niveau en attente. Utilisez `openclaw devices list` pour comparer l’accès actuellement approuvé avec l’accès nouvellement demandé avant d’approuver.
|
||||
</Note>
|
||||
|
||||
### Approbation automatique optionnelle des nœuds par CIDR de confiance
|
||||
### Approbation automatique optionnelle de Node par CIDR de confiance
|
||||
|
||||
L’appairage d’appareils reste manuel par défaut. Pour les réseaux de nœuds étroitement contrôlés,
|
||||
vous pouvez choisir d’activer l’approbation automatique de premier appairage de nœud avec des CIDR explicites ou des IP exactes :
|
||||
L’appairage d’appareil reste manuel par défaut. Pour des réseaux Node strictement contrôlés,
|
||||
vous pouvez activer l’approbation automatique des nouveaux Node avec des CIDR explicites ou des IP exactes :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -181,35 +186,35 @@ vous pouvez choisir d’activer l’approbation automatique de premier appairage
|
||||
}
|
||||
```
|
||||
|
||||
Cela s’applique uniquement aux nouvelles demandes d’appairage `role: node` sans
|
||||
portées demandées. Les clients operator, navigateur, Control UI et WebChat exigent toujours une approbation
|
||||
manuelle. Les changements de rôle, de portée, de métadonnées et de clé publique exigent toujours une approbation
|
||||
Cela ne s’applique qu’aux nouvelles demandes d’appairage `role: node` sans portées demandées.
|
||||
Les clients operator, navigateur, Control UI et WebChat exigent toujours une approbation manuelle.
|
||||
Les changements de rôle, de portée, de métadonnées et de clé publique exigent toujours une approbation
|
||||
manuelle.
|
||||
|
||||
### Stockage de l’état d’appairage Node
|
||||
|
||||
Stocké sous `~/.openclaw/devices/` :
|
||||
|
||||
- `pending.json` (éphémère ; les demandes en attente expirent)
|
||||
- `pending.json` (courte durée ; les demandes en attente expirent)
|
||||
- `paired.json` (appareils appairés + jetons)
|
||||
|
||||
### Notes
|
||||
|
||||
- L’ancienne API `node.pair.*` (CLI : `openclaw nodes pending|approve|reject|remove|rename`) est un
|
||||
magasin d’appairage séparé, détenu par le Gateway. Les nœuds WS exigent toujours l’appairage d’appareils.
|
||||
- L’enregistrement d’appairage est la source de vérité durable pour les rôles approuvés. Les jetons d’appareil
|
||||
actifs restent limités à cet ensemble de rôles approuvé ; une entrée de jeton isolée
|
||||
hors des rôles approuvés ne crée pas de nouvel accès.
|
||||
magasin d’appairage séparé appartenant au Gateway. Les nœuds WS exigent toujours l’appairage d’appareil.
|
||||
- L’enregistrement d’appairage est la source de vérité durable pour les rôles approuvés. Les jetons
|
||||
d’appareil actifs restent limités à cet ensemble de rôles approuvé ; une entrée de jeton isolée
|
||||
en dehors des rôles approuvés ne crée pas de nouvel accès.
|
||||
|
||||
## Documentation associée
|
||||
## Docs associées
|
||||
|
||||
- Modèle de sécurité + injection de prompt : [Sécurité](/fr/gateway/security)
|
||||
- Mettre à jour en toute sécurité (exécuter doctor) : [Mise à jour](/fr/install/updating)
|
||||
- Mise à jour en sécurité (exécuter doctor) : [Mise à jour](/fr/install/updating)
|
||||
- Configurations de canaux :
|
||||
- Telegram : [Telegram](/fr/channels/telegram)
|
||||
- WhatsApp : [WhatsApp](/fr/channels/whatsapp)
|
||||
- Signal : [Signal](/fr/channels/signal)
|
||||
- BlueBubbles (iMessage) : [BlueBubbles](/fr/channels/bluebubbles)
|
||||
- iMessage (ancien) : [iMessage](/fr/channels/imessage)
|
||||
- iMessage (hérité) : [iMessage](/fr/channels/imessage)
|
||||
- Discord : [Discord](/fr/channels/discord)
|
||||
- Slack : [Slack](/fr/channels/slack)
|
||||
|
||||
@ -1,29 +1,29 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous souhaitez utiliser le Gateway depuis un navigateur
|
||||
- Vous voulez utiliser le Gateway depuis un navigateur
|
||||
- Vous voulez accéder au Tailnet sans tunnels SSH
|
||||
sidebarTitle: Control UI
|
||||
summary: Interface de contrôle basée sur navigateur pour le Gateway (discussion, nœuds, configuration)
|
||||
summary: Interface de contrôle basée sur le navigateur pour le Gateway (chat, nœuds, configuration)
|
||||
title: Interface de contrôle
|
||||
x-i18n:
|
||||
generated_at: "2026-05-04T07:06:32Z"
|
||||
generated_at: "2026-05-04T07:21:38Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 07fbbe1c7fec5f67a04a231e02bdf0f7d16be9c5fe188915674d71fcd69002a5
|
||||
source_hash: 896c75116d7a396571017ac6e6db7ff6ce328617e44470c303fd41af58aa2bd7
|
||||
source_path: web/control-ui.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
La Control UI est une petite application monopage **Vite + Lit** servie par le Gateway :
|
||||
L’interface de contrôle est une petite application monopage **Vite + Lit** servie par le Gateway :
|
||||
|
||||
- par défaut : `http://<host>:18789/`
|
||||
- préfixe facultatif : définissez `gateway.controlUi.basePath` (p. ex. `/openclaw`)
|
||||
- préfixe facultatif : définissez `gateway.controlUi.basePath` (par exemple `/openclaw`)
|
||||
|
||||
Elle communique **directement avec le WebSocket du Gateway** sur le même port.
|
||||
|
||||
## Ouverture rapide (locale)
|
||||
## Ouverture rapide (local)
|
||||
|
||||
Si le Gateway s’exécute sur le même ordinateur, ouvrez :
|
||||
Si le Gateway est en cours d’exécution sur le même ordinateur, ouvrez :
|
||||
|
||||
- [http://127.0.0.1:18789/](http://127.0.0.1:18789/) (ou [http://localhost:18789/](http://localhost:18789/))
|
||||
|
||||
@ -34,13 +34,13 @@ L’authentification est fournie pendant la négociation WebSocket via :
|
||||
- `connect.params.auth.token`
|
||||
- `connect.params.auth.password`
|
||||
- les en-têtes d’identité Tailscale Serve lorsque `gateway.auth.allowTailscale: true`
|
||||
- les en-têtes d’identité de proxy de confiance lorsque `gateway.auth.mode: "trusted-proxy"`
|
||||
- les en-têtes d’identité du proxy approuvé lorsque `gateway.auth.mode: "trusted-proxy"`
|
||||
|
||||
Le panneau de paramètres du tableau de bord conserve un jeton pour la session de l’onglet de navigateur actuel et l’URL de Gateway sélectionnée ; les mots de passe ne sont pas persistés. L’intégration génère généralement un jeton de Gateway pour l’authentification par secret partagé lors de la première connexion, mais l’authentification par mot de passe fonctionne aussi lorsque `gateway.auth.mode` vaut `"password"`.
|
||||
Le panneau des paramètres du tableau de bord conserve un jeton pour la session de l’onglet de navigateur actuel et l’URL de gateway sélectionnée ; les mots de passe ne sont pas conservés. L’intégration génère généralement un jeton de gateway pour l’authentification par secret partagé à la première connexion, mais l’authentification par mot de passe fonctionne aussi lorsque `gateway.auth.mode` vaut `"password"`.
|
||||
|
||||
## Appairage d’appareil (première connexion)
|
||||
|
||||
Lorsque vous vous connectez à la Control UI depuis un nouveau navigateur ou appareil, le Gateway exige généralement une **approbation d’appairage unique**. Il s’agit d’une mesure de sécurité destinée à empêcher les accès non autorisés.
|
||||
Lorsque vous vous connectez à l’interface de contrôle depuis un nouveau navigateur ou appareil, le Gateway exige généralement une **approbation d’appairage unique**. Il s’agit d’une mesure de sécurité destinée à empêcher tout accès non autorisé.
|
||||
|
||||
**Ce que vous verrez :** « disconnected (1008): pairing required »
|
||||
|
||||
@ -57,15 +57,15 @@ Lorsque vous vous connectez à la Control UI depuis un nouveau navigateur ou app
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Si le navigateur retente l’appairage avec des détails d’authentification modifiés (rôle/portées/clé publique), la demande en attente précédente est remplacée et un nouveau `requestId` est créé. Réexécutez `openclaw devices list` avant l’approbation.
|
||||
Si le navigateur relance l’appairage avec des détails d’authentification modifiés (rôle/portées/clé publique), la demande en attente précédente est remplacée et un nouveau `requestId` est créé. Relancez `openclaw devices list` avant l’approbation.
|
||||
|
||||
Si le navigateur est déjà appairé et que vous le faites passer d’un accès en lecture à un accès en écriture/administration, cela est traité comme une mise à niveau d’approbation, et non comme une reconnexion silencieuse. OpenClaw conserve l’ancienne approbation active, bloque la reconnexion plus étendue et vous demande d’approuver explicitement le nouvel ensemble de portées.
|
||||
Si le navigateur est déjà appairé et que vous le faites passer d’un accès en lecture à un accès en écriture/administration, cela est traité comme une mise à niveau d’approbation, et non comme une reconnexion silencieuse. OpenClaw conserve l’ancienne approbation active, bloque la reconnexion plus large et vous demande d’approuver explicitement le nouvel ensemble de portées.
|
||||
|
||||
Une fois approuvé, l’appareil est mémorisé et ne demandera plus de nouvelle approbation, sauf si vous le révoquez avec `openclaw devices revoke --device <id> --role <role>`. Consultez [CLI des appareils](/fr/cli/devices) pour la rotation et la révocation des jetons.
|
||||
Une fois approuvé, l’appareil est mémorisé et ne nécessitera pas de nouvelle approbation, sauf si vous le révoquez avec `openclaw devices revoke --device <id> --role <role>`. Consultez [CLI des appareils](/fr/cli/devices) pour la rotation et la révocation des jetons.
|
||||
|
||||
<Note>
|
||||
- Les connexions directes de navigateur en local loopback (`127.0.0.1` / `localhost`) sont approuvées automatiquement.
|
||||
- Tailscale Serve peut ignorer l’aller-retour d’appairage pour les sessions opérateur de la Control UI lorsque `gateway.auth.allowTailscale: true`, que l’identité Tailscale est vérifiée et que le navigateur présente son identité d’appareil.
|
||||
- Les connexions directes depuis un navigateur en local loopback (`127.0.0.1` / `localhost`) sont approuvées automatiquement.
|
||||
- Tailscale Serve peut éviter l’aller-retour d’appairage pour les sessions opérateur de l’interface de contrôle lorsque `gateway.auth.allowTailscale: true`, que l’identité Tailscale est vérifiée et que le navigateur présente son identité d’appareil.
|
||||
- Les liaisons Tailnet directes, les connexions de navigateur sur le LAN et les profils de navigateur sans identité d’appareil nécessitent toujours une approbation explicite.
|
||||
- Chaque profil de navigateur génère un ID d’appareil unique ; changer de navigateur ou effacer les données du navigateur nécessitera donc un nouvel appairage.
|
||||
|
||||
@ -73,80 +73,81 @@ Une fois approuvé, l’appareil est mémorisé et ne demandera plus de nouvelle
|
||||
|
||||
## Identité personnelle (locale au navigateur)
|
||||
|
||||
La Control UI prend en charge une identité personnelle par navigateur (nom d’affichage et avatar) attachée aux messages sortants pour l’attribution dans les sessions partagées. Elle réside dans le stockage du navigateur, est limitée au profil de navigateur actuel et n’est pas synchronisée avec d’autres appareils ni persistée côté serveur au-delà des métadonnées normales d’auteur de transcript sur les messages que vous envoyez réellement. Effacer les données du site ou changer de navigateur la réinitialise à une valeur vide.
|
||||
L’interface de contrôle prend en charge une identité personnelle propre à chaque navigateur (nom d’affichage et avatar), attachée aux messages sortants pour l’attribution dans les sessions partagées. Elle réside dans le stockage du navigateur, est limitée au profil de navigateur actuel et n’est pas synchronisée avec d’autres appareils ni conservée côté serveur au-delà des métadonnées normales d’auteur de transcript sur les messages que vous envoyez réellement. Effacer les données du site ou changer de navigateur la réinitialise à vide.
|
||||
|
||||
Le même modèle local au navigateur s’applique au remplacement de l’avatar de l’assistant. Les avatars d’assistant téléversés superposent l’identité résolue par le Gateway dans le navigateur local uniquement et ne font jamais d’aller-retour via `config.patch`. Le champ de configuration partagé `ui.assistant.avatar` reste disponible pour les clients non-UI qui écrivent directement dans ce champ (comme les gateways scriptés ou les tableaux de bord personnalisés).
|
||||
Le même modèle local au navigateur s’applique à la substitution de l’avatar de l’assistant. Les avatars d’assistant téléversés remplacent l’identité résolue par le gateway uniquement dans le navigateur local et ne transitent jamais via `config.patch`. Le champ de configuration partagé `ui.assistant.avatar` reste disponible pour les clients non UI qui écrivent directement ce champ (comme les gateways scriptés ou les tableaux de bord personnalisés).
|
||||
|
||||
## Point de terminaison de configuration d’exécution
|
||||
## Endpoint de configuration d’exécution
|
||||
|
||||
La Control UI récupère ses paramètres d’exécution depuis `/__openclaw/control-ui-config.json`. Ce point de terminaison est protégé par la même authentification de Gateway que le reste de la surface HTTP : les navigateurs non authentifiés ne peuvent pas le récupérer, et une récupération réussie nécessite soit un jeton/mot de passe de Gateway déjà valide, soit une identité Tailscale Serve, soit une identité de proxy de confiance.
|
||||
L’interface de contrôle récupère ses paramètres d’exécution depuis `/__openclaw/control-ui-config.json`. Cet endpoint est protégé par la même authentification de gateway que le reste de la surface HTTP : les navigateurs non authentifiés ne peuvent pas le récupérer, et une récupération réussie exige soit un jeton/mot de passe de gateway déjà valide, soit une identité Tailscale Serve, soit une identité de proxy approuvé.
|
||||
|
||||
## Prise en charge des langues
|
||||
|
||||
La Control UI peut se localiser au premier chargement selon la locale de votre navigateur. Pour la remplacer plus tard, ouvrez **Vue d’ensemble -> Accès au Gateway -> Langue**. Le sélecteur de locale se trouve dans la carte Accès au Gateway, pas sous Apparence.
|
||||
L’interface de contrôle peut se localiser au premier chargement selon la langue de votre navigateur. Pour la modifier plus tard, ouvrez **Vue d’ensemble -> Accès au Gateway -> Langue**. Le sélecteur de langue se trouve dans la carte Accès au Gateway, pas sous Apparence.
|
||||
|
||||
- Locales prises en charge : `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
|
||||
- Les traductions non anglaises sont chargées paresseusement dans le navigateur.
|
||||
- La locale sélectionnée est enregistrée dans le stockage du navigateur et réutilisée lors des visites futures.
|
||||
- Les clés de traduction manquantes se rabattent sur l’anglais.
|
||||
- Langues prises en charge : `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
|
||||
- Les traductions non anglaises sont chargées à la demande dans le navigateur.
|
||||
- La langue sélectionnée est enregistrée dans le stockage du navigateur et réutilisée lors des visites futures.
|
||||
- Les clés de traduction manquantes reviennent à l’anglais.
|
||||
|
||||
Les traductions de la documentation sont générées pour le même ensemble de locales non anglaises, mais le sélecteur de langue Mintlify intégré au site de documentation est limité aux codes de locale acceptés par Mintlify. Les docs en thaï (`th`) et en persan (`fa`) sont quand même générées dans le dépôt de publication ; elles peuvent ne pas apparaître dans ce sélecteur tant que Mintlify ne prend pas en charge ces codes.
|
||||
Les traductions de la documentation sont générées pour le même ensemble de langues non anglaises, mais le sélecteur de langue Mintlify intégré au site de documentation est limité aux codes de langue acceptés par Mintlify. La documentation en thaï (`th`) et en persan (`fa`) est tout de même générée dans le dépôt de publication ; elle peut ne pas apparaître dans ce sélecteur tant que Mintlify ne prend pas en charge ces codes.
|
||||
|
||||
## Thèmes d’apparence
|
||||
|
||||
Le panneau Apparence conserve les thèmes intégrés Claw, Knot et Dash, ainsi qu’un emplacement d’import tweakcn local au navigateur. Pour importer un thème, ouvrez [l’éditeur tweakcn](https://tweakcn.com/editor/theme), choisissez ou créez un thème, cliquez sur **Partager**, puis collez le lien de thème copié dans Apparence. L’importateur accepte aussi les URL de registre `https://tweakcn.com/r/themes/<id>`, les URL d’éditeur comme `https://tweakcn.com/editor/theme?theme=amethyst-haze`, les chemins relatifs `/themes/<id>`, les ID de thème bruts et les noms de thème par défaut comme `amethyst-haze`.
|
||||
|
||||
Les thèmes importés sont stockés uniquement dans le profil de navigateur actuel. Ils ne sont pas écrits dans la configuration du Gateway et ne se synchronisent pas entre appareils. Remplacer le thème importé met à jour l’unique emplacement local ; l’effacer fait revenir le thème actif à Claw si le thème importé était sélectionné.
|
||||
Les thèmes importés sont stockés uniquement dans le profil de navigateur actuel. Ils ne sont pas écrits dans la configuration du gateway et ne se synchronisent pas entre les appareils. Remplacer le thème importé met à jour l’unique emplacement local ; l’effacer rebascule le thème actif vers Claw si le thème importé était sélectionné.
|
||||
|
||||
## Ce qu’elle peut faire (aujourd’hui)
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Chat et conversation vocale">
|
||||
- Discuter avec le modèle via le WS du Gateway (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
|
||||
- Parler via des sessions temps réel dans le navigateur. OpenAI utilise WebRTC direct, Google Live utilise un jeton de navigateur contraint à usage unique sur WebSocket, et les plugins de voix temps réel côté backend uniquement utilisent le transport de relais du Gateway. Le relais conserve les identifiants de fournisseur sur le Gateway pendant que le navigateur diffuse le PCM du microphone via les RPC `talk.realtime.relay*` et renvoie les appels d’outil `openclaw_agent_consult` via `chat.send` pour le plus grand modèle OpenClaw configuré.
|
||||
- Diffuser les appels d’outil + les cartes de sortie d’outil en direct dans Chat (événements d’agent).
|
||||
- Discuter avec le modèle via le Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
|
||||
- Parler via des sessions temps réel du navigateur. OpenAI utilise WebRTC direct, Google Live utilise un jeton de navigateur contraint à usage unique sur WebSocket, et les plugins de voix temps réel côté backend uniquement utilisent le transport relais du Gateway. Le relais conserve les identifiants du fournisseur sur le Gateway pendant que le navigateur diffuse le PCM du microphone via les RPC `talk.realtime.relay*` et renvoie les appels d’outil `openclaw_agent_consult` via `chat.send` vers le modèle OpenClaw configuré plus large.
|
||||
- Diffuser les appels d’outils + les cartes de sortie d’outils en direct dans Chat (événements d’agent).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Canaux, instances, sessions, rêves">
|
||||
- Canaux : statut des canaux intégrés et des canaux de plugins groupés/externes, connexion par QR code et configuration par canal (`channels.status`, `web.login.*`, `config.patch`).
|
||||
- Canaux : état des canaux intégrés et des canaux de plugins groupés/externes, connexion par QR code et configuration par canal (`channels.status`, `web.login.*`, `config.patch`).
|
||||
- Instances : liste de présence + actualisation (`system-presence`).
|
||||
- Sessions : liste + remplacements par session pour le modèle/la réflexion/le mode rapide/le mode verbeux/la trace/le raisonnement (`sessions.list`, `sessions.patch`).
|
||||
- Rêves : statut de Dreaming, bascule d’activation/désactivation et lecteur du journal des rêves (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
|
||||
- Sessions : liste + substitutions par session pour modèle/thinking/rapide/verbeux/trace/reasoning (`sessions.list`, `sessions.patch`).
|
||||
- Rêves : état de Dreaming, bascule activer/désactiver et lecteur du journal de rêves (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Cron, Skills, Nodes, approbations exec">
|
||||
- Tâches Cron : lister/ajouter/modifier/exécuter/activer/désactiver + historique d’exécution (`cron.*`).
|
||||
- Skills : statut, activation/désactivation, installation, mises à jour de clé API (`skills.*`).
|
||||
- Skills : état, activer/désactiver, installer, mises à jour de clé API (`skills.*`).
|
||||
- Nodes : liste + capacités (`node.list`).
|
||||
- Approbations exec : modifier les listes d’autorisation du Gateway ou des Nodes + politique de demande pour `exec host=gateway/node` (`exec.approvals.*`).
|
||||
- Approbations exec : modifier les listes d’autorisation du gateway ou du node + politique de demande pour `exec host=gateway/node` (`exec.approvals.*`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Configuration">
|
||||
- Afficher/modifier `~/.openclaw/openclaw.json` (`config.get`, `config.set`).
|
||||
- Appliquer + redémarrer avec validation (`config.apply`) et réveiller la dernière session active.
|
||||
- Les écritures incluent une garde par hachage de base pour éviter d’écraser des modifications concurrentes.
|
||||
- Les écritures (`config.set`/`config.apply`/`config.patch`) prévalident la résolution des SecretRef actifs pour les références dans la charge utile de configuration soumise ; les références actives soumises non résolues sont rejetées avant l’écriture.
|
||||
- Schéma + rendu de formulaire (`config.schema` / `config.schema.lookup`, y compris les champs `title` / `description`, les indices d’interface correspondants, les résumés d’enfants immédiats, les métadonnées de documentation sur les nœuds objet imbriqué/joker/tableau/composition, ainsi que les schémas de plugin + canal lorsqu’ils sont disponibles) ; l’éditeur JSON brut est disponible uniquement lorsque l’instantané dispose d’un aller-retour brut sûr.
|
||||
- Si un instantané ne peut pas effectuer en toute sécurité l’aller-retour du texte brut, la Control UI force le mode Formulaire et désactive le mode Brut pour cet instantané.
|
||||
- La commande « Réinitialiser à l’enregistré » de l’éditeur JSON brut préserve la forme rédigée en brut (mise en forme, commentaires, disposition `$include`) au lieu de rerendre un instantané aplati, afin que les modifications externes survivent à une réinitialisation lorsque l’instantané peut effectuer un aller-retour sûr.
|
||||
- Les valeurs d’objet SecretRef structurées sont rendues en lecture seule dans les entrées de texte du formulaire pour éviter une corruption accidentelle d’objet vers chaîne.
|
||||
- Les écritures (`config.set`/`config.apply`/`config.patch`) prévalident la résolution active des SecretRef pour les références dans la charge utile de configuration soumise ; les références soumises actives non résolues sont rejetées avant l’écriture.
|
||||
- Schéma + rendu de formulaire (`config.schema` / `config.schema.lookup`, y compris les champs `title` / `description`, les indications UI correspondantes, les résumés des enfants immédiats, les métadonnées de documentation sur les nœuds objet imbriqué/joker/tableau/composition, ainsi que les schémas de plugin + canal lorsqu’ils sont disponibles) ; l’éditeur JSON brut n’est disponible que lorsque l’instantané permet un aller-retour brut sûr.
|
||||
- Si un instantané ne peut pas effectuer en toute sécurité un aller-retour du texte brut, l’interface de contrôle force le mode Formulaire et désactive le mode Brut pour cet instantané.
|
||||
- Dans l’éditeur JSON brut, « Réinitialiser vers la version enregistrée » conserve la forme rédigée en brut (formatage, commentaires, disposition `$include`) au lieu de restituer un instantané aplati, de sorte que les modifications externes survivent à une réinitialisation lorsque l’instantané peut effectuer un aller-retour sûr.
|
||||
- Les valeurs d’objet SecretRef structurées sont rendues en lecture seule dans les champs texte du formulaire afin d’éviter une corruption accidentelle d’objet en chaîne.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Débogage, journaux, mise à jour">
|
||||
- Débogage : instantanés de statut/santé/modèles + journal d’événements + appels RPC manuels (`status`, `health`, `models.list`).
|
||||
- Journaux : suivi en direct des journaux de fichier du Gateway avec filtre/export (`logs.tail`).
|
||||
- Mise à jour : exécuter une mise à jour de package/git + redémarrer (`update.run`) avec un rapport de redémarrage, puis interroger `update.status` après reconnexion pour vérifier la version du Gateway en cours d’exécution.
|
||||
- Débogage : instantanés d’état/santé/modèles + journal d’événements + appels RPC manuels (`status`, `health`, `models.list`).
|
||||
- Le journal d’événements inclut les minutages d’actualisation/RPC de l’interface de contrôle ainsi que les entrées de réactivité du navigateur pour les longues images d’animation ou les tâches longues lorsque le navigateur expose ces types d’entrées PerformanceObserver.
|
||||
- Journaux : suivi en direct des journaux de fichiers du gateway avec filtre/export (`logs.tail`).
|
||||
- Mise à jour : exécuter une mise à jour package/git + redémarrage (`update.run`) avec un rapport de redémarrage, puis interroger `update.status` après reconnexion pour vérifier la version du gateway en cours d’exécution.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Notes du panneau des tâches Cron">
|
||||
- Pour les tâches isolées, la livraison annonce un résumé par défaut. Vous pouvez passer à aucune si vous voulez des exécutions internes uniquement.
|
||||
- Pour les tâches isolées, la livraison annonce le résumé par défaut. Vous pouvez passer à aucune si vous voulez des exécutions internes uniquement.
|
||||
- Les champs canal/cible apparaissent lorsque l’annonce est sélectionnée.
|
||||
- Le mode Webhook utilise `delivery.mode = "webhook"` avec `delivery.to` défini sur une URL Webhook HTTP(S) valide.
|
||||
- Pour les tâches de session principale, les modes de livraison Webhook et aucune sont disponibles.
|
||||
- Les contrôles d’édition avancée incluent supprimer après exécution, effacer le remplacement d’agent, options Cron exact/décalage, remplacements du modèle/de la réflexion de l’agent et bascules de livraison au mieux.
|
||||
- La validation du formulaire est intégrée avec des erreurs au niveau des champs ; les valeurs invalides désactivent le bouton d’enregistrement jusqu’à correction.
|
||||
- Définissez `cron.webhookToken` pour envoyer un jeton bearer dédié ; s’il est omis, le Webhook est envoyé sans en-tête d’authentification.
|
||||
- Solution de repli obsolète : les anciennes tâches stockées avec `notify: true` peuvent encore utiliser `cron.webhook` jusqu’à migration.
|
||||
- Le mode Webhook utilise `delivery.mode = "webhook"` avec `delivery.to` défini sur une URL de webhook HTTP(S) valide.
|
||||
- Pour les tâches de session principale, les modes de livraison webhook et aucune sont disponibles.
|
||||
- Les contrôles de modification avancés incluent suppression après exécution, effacement de la substitution d’agent, options cron exact/décalage, substitutions de modèle/thinking d’agent et bascules de livraison au mieux.
|
||||
- La validation du formulaire est en ligne avec des erreurs au niveau des champs ; les valeurs invalides désactivent le bouton d’enregistrement jusqu’à correction.
|
||||
- Définissez `cron.webhookToken` pour envoyer un jeton bearer dédié ; s’il est omis, le webhook est envoyé sans en-tête d’authentification.
|
||||
- Solution de secours obsolète : les anciennes tâches stockées avec `notify: true` peuvent toujours utiliser `cron.webhook` jusqu’à migration.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -154,63 +155,63 @@ Les thèmes importés sont stockés uniquement dans le profil de navigateur actu
|
||||
## Comportement du chat
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Send and history semantics">
|
||||
- `chat.send` est **non bloquant** : il accuse réception immédiatement avec `{ runId, status: "started" }` et la réponse est diffusée via des événements `chat`.
|
||||
- Les téléversements de chat acceptent les images ainsi que les fichiers non vidéo. Les images conservent le chemin d’image natif ; les autres fichiers sont stockés comme médias gérés et affichés dans l’historique sous forme de liens de pièces jointes.
|
||||
- Un nouvel envoi avec le même `idempotencyKey` renvoie `{ status: "in_flight" }` pendant l’exécution, puis `{ status: "ok" }` après la fin.
|
||||
- Les réponses `chat.history` sont limitées en taille pour la sécurité de l’interface utilisateur. Lorsque les entrées de transcription sont trop volumineuses, le Gateway peut tronquer les champs de texte longs, omettre les blocs de métadonnées lourds et remplacer les messages surdimensionnés par un espace réservé (`[chat.history omitted: message too large]`).
|
||||
- Les images d’assistant/générées sont conservées comme références de médias gérés et resservies via des URL de médias authentifiées du Gateway, afin que les rechargements ne dépendent pas de la présence durable des charges utiles d’image base64 brutes dans la réponse d’historique du chat.
|
||||
- `chat.history` supprime également les balises de directives en ligne uniquement destinées à l’affichage du texte visible de l’assistant (par exemple `[[reply_to_*]]` et `[[audio_as_voice]]`), les charges utiles XML d’appels d’outils en texte brut (y compris `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` et les blocs d’appels d’outils tronqués), ainsi que les jetons de contrôle de modèle ASCII/pleine chasse divulgués, et omet les entrées d’assistant dont tout le texte visible est uniquement le jeton silencieux exact `NO_REPLY` / `no_reply`.
|
||||
- Pendant un envoi actif et l’actualisation finale de l’historique, la vue de chat garde visibles les messages utilisateur/assistant optimistes locaux si `chat.history` renvoie brièvement un instantané plus ancien ; la transcription canonique remplace ces messages locaux une fois que l’historique du Gateway a rattrapé son retard.
|
||||
- Les événements `chat` en direct représentent l’état de livraison, tandis que `chat.history` est reconstruit à partir de la transcription durable de la session. Après les événements finaux d’outils, l’interface Control recharge l’historique et ne fusionne qu’une petite fin optimiste ; la limite de transcription est documentée dans [WebChat](/fr/web/webchat).
|
||||
- `chat.inject` ajoute une note d’assistant à la transcription de session et diffuse un événement `chat` pour les mises à jour uniquement destinées à l’interface utilisateur (aucune exécution d’agent, aucune livraison de canal).
|
||||
- Le modèle d’en-tête du chat et les sélecteurs de réflexion modifient immédiatement la session active via `sessions.patch` ; ce sont des remplacements persistants de session, et non des options d’envoi limitées à un seul tour.
|
||||
- Saisir `/new` dans l’interface Control crée et bascule vers la même nouvelle session de tableau de bord que Nouveau chat. Saisir `/reset` conserve la réinitialisation explicite en place du Gateway pour la session actuelle.
|
||||
- Le sélecteur de modèle de chat demande la vue de modèle configurée du Gateway. Si `agents.defaults.models` est présent, cette liste d’autorisation pilote le sélecteur. Sinon, le sélecteur affiche les entrées explicites `models.providers.*.models` ainsi que les fournisseurs avec une authentification utilisable. Le catalogue complet reste disponible via le RPC de débogage `models.list` avec `view: "all"`.
|
||||
- Lorsque les rapports d’utilisation d’une session Gateway fraîche indiquent une forte pression de contexte, la zone de composition du chat affiche un avis de contexte et, aux niveaux de Compaction recommandés, un bouton compact qui exécute le chemin normal de Compaction de session. Les instantanés de jetons obsolètes sont masqués jusqu’à ce que le Gateway signale à nouveau une utilisation fraîche.
|
||||
<Accordion title="Sémantique d’envoi et d’historique">
|
||||
- `chat.send` est **non bloquant** : il acquitte immédiatement avec `{ runId, status: "started" }` et la réponse est diffusée via les événements `chat`.
|
||||
- Les téléversements de chat acceptent les images ainsi que les fichiers non vidéo. Les images conservent le chemin d’image natif ; les autres fichiers sont stockés comme médias gérés et affichés dans l’historique sous forme de liens de pièce jointe.
|
||||
- Un nouvel envoi avec le même `idempotencyKey` renvoie `{ status: "in_flight" }` pendant l’exécution, puis `{ status: "ok" }` après l’achèvement.
|
||||
- Les réponses `chat.history` ont une taille limitée pour préserver la sécurité de l’interface utilisateur. Lorsque les entrées de transcription sont trop volumineuses, le Gateway peut tronquer les longs champs de texte, omettre les blocs de métadonnées lourds et remplacer les messages trop volumineux par un espace réservé (`[chat.history omitted: message too large]`).
|
||||
- Les images d’assistant/générées sont conservées comme références de médias gérés et resservies via des URL de médias Gateway authentifiées ; ainsi, les rechargements ne dépendent pas du maintien de charges utiles d’images base64 brutes dans la réponse de l’historique de chat.
|
||||
- `chat.history` supprime aussi du texte visible de l’assistant les balises de directives intégrées destinées uniquement à l’affichage (par exemple `[[reply_to_*]]` et `[[audio_as_voice]]`), les charges utiles XML d’appels d’outils en texte brut (y compris `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` et les blocs d’appels d’outils tronqués), ainsi que les tokens de contrôle de modèle ASCII/pleine chasse divulgués, et omet les entrées d’assistant dont tout le texte visible n’est que le token silencieux exact `NO_REPLY` / `no_reply`.
|
||||
- Pendant un envoi actif et le rafraîchissement final de l’historique, la vue de chat garde visibles les messages utilisateur/assistant optimistes locaux si `chat.history` renvoie brièvement un instantané plus ancien ; la transcription canonique remplace ces messages locaux lorsque l’historique du Gateway se synchronise.
|
||||
- Les événements `chat` en direct représentent l’état de livraison, tandis que `chat.history` est reconstruit à partir de la transcription durable de session. Après les événements finaux d’outils, la Control UI recharge l’historique et ne fusionne qu’une petite queue optimiste ; la limite de transcription est documentée dans [WebChat](/fr/web/webchat).
|
||||
- `chat.inject` ajoute une note d’assistant à la transcription de session et diffuse un événement `chat` pour les mises à jour réservées à l’interface utilisateur (aucune exécution d’agent, aucune livraison de canal).
|
||||
- Les sélecteurs de modèle et de réflexion de l’en-tête de chat modifient immédiatement la session active via `sessions.patch` ; ce sont des remplacements persistants de session, et non des options d’envoi limitées à un seul tour.
|
||||
- Saisir `/new` dans la Control UI crée et bascule vers la même session de tableau de bord fraîche que New Chat. Saisir `/reset` conserve la réinitialisation explicite sur place du Gateway pour la session actuelle.
|
||||
- Le sélecteur de modèle de chat demande la vue de modèles configurée du Gateway. Si `agents.defaults.models` est présent, cette liste d’autorisation pilote le sélecteur. Sinon, le sélecteur affiche les entrées explicites `models.providers.*.models` ainsi que les fournisseurs disposant d’une authentification utilisable. Le catalogue complet reste disponible via le RPC de débogage `models.list` avec `view: "all"`.
|
||||
- Lorsque les rapports récents d’utilisation de session du Gateway indiquent une forte pression de contexte, la zone de composition du chat affiche un avis de contexte et, aux niveaux de compaction recommandés, un bouton de compaction qui exécute le chemin normal de Compaction de session. Les instantanés de tokens obsolètes sont masqués jusqu’à ce que le Gateway signale à nouveau une utilisation fraîche.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Talk mode (browser realtime)">
|
||||
Le mode Parler utilise un fournisseur vocal temps réel enregistré. Configurez OpenAI avec `talk.provider: "openai"` plus `talk.providers.openai.apiKey`, ou configurez Google avec `talk.provider: "google"` plus `talk.providers.google.apiKey` ; la configuration du fournisseur temps réel Voice Call peut encore être réutilisée comme solution de repli. Le navigateur ne reçoit jamais de clé API de fournisseur standard. OpenAI reçoit un secret client Realtime éphémère pour WebRTC. Google Live reçoit un jeton d’authentification Live API contraint à usage unique pour une session WebSocket de navigateur, avec les instructions et déclarations d’outils verrouillées dans le jeton par le Gateway. Les fournisseurs qui exposent uniquement un pont temps réel dorsal passent par le transport relais du Gateway, de sorte que les identifiants et les sockets fournisseur restent côté serveur tandis que l’audio du navigateur transite par des RPC Gateway authentifiés. L’invite de session Realtime est assemblée par le Gateway ; `talk.realtime.session` n’accepte pas les remplacements d’instructions fournis par l’appelant.
|
||||
<Accordion title="Mode Talk (temps réel dans le navigateur)">
|
||||
Le mode Talk utilise un fournisseur vocal temps réel enregistré. Configurez OpenAI avec `talk.provider: "openai"` plus `talk.providers.openai.apiKey`, ou configurez Google avec `talk.provider: "google"` plus `talk.providers.google.apiKey` ; la configuration du fournisseur temps réel Voice Call peut toujours être réutilisée comme solution de repli. Le navigateur ne reçoit jamais de clé API de fournisseur standard. OpenAI reçoit un secret client Realtime éphémère pour WebRTC. Google Live reçoit un token d’authentification Live API contraint et à usage unique pour une session WebSocket de navigateur, avec les instructions et déclarations d’outils verrouillées dans le token par le Gateway. Les fournisseurs qui n’exposent qu’un pont temps réel côté backend passent par le transport relais du Gateway, de sorte que les identifiants et les sockets fournisseur restent côté serveur tandis que l’audio du navigateur circule via des RPC Gateway authentifiés. Le prompt de session Realtime est assemblé par le Gateway ; `talk.realtime.session` n’accepte pas de remplacements d’instructions fournis par l’appelant.
|
||||
|
||||
Dans le compositeur de Chat, le contrôle Parler est le bouton à vagues à côté du bouton de dictée au microphone. Lorsque Parler démarre, la ligne d’état du compositeur affiche `Connecting Talk...`, puis `Talk live` pendant que l’audio est connecté, ou `Asking OpenClaw...` pendant qu’un appel d’outil temps réel consulte le modèle plus grand configuré via `chat.send`.
|
||||
Dans le compositeur de chat, le contrôle Talk est le bouton à ondes à côté du bouton de dictée au microphone. Lorsque Talk démarre, la ligne d’état du compositeur affiche `Connecting Talk...`, puis `Talk live` pendant que l’audio est connecté, ou `Asking OpenClaw...` lorsqu’un appel d’outil temps réel consulte le modèle plus grand configuré via `chat.send`.
|
||||
|
||||
Smoke en direct pour mainteneur : `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` vérifie l’échange SDP WebRTC navigateur d’OpenAI, la configuration WebSocket navigateur à jeton contraint de Google Live et l’adaptateur navigateur relais du Gateway avec un média de microphone simulé. La commande n’affiche que l’état du fournisseur et ne journalise pas les secrets.
|
||||
Smoke test live mainteneur : `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` vérifie l’échange SDP WebRTC du navigateur OpenAI, la configuration WebSocket de navigateur à token contraint Google Live et l’adaptateur de navigateur relais du Gateway avec un faux média de microphone. La commande n’affiche que l’état du fournisseur et ne journalise pas de secrets.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Stop and abort">
|
||||
<Accordion title="Arrêt et abandon">
|
||||
- Cliquez sur **Arrêter** (appelle `chat.abort`).
|
||||
- Pendant qu’une exécution est active, les suivis normaux sont mis en file d’attente. Cliquez sur **Orienter** sur un message en file d’attente pour injecter ce suivi dans le tour en cours.
|
||||
- Pendant qu’une exécution est active, les suivis normaux sont mis en file d’attente. Cliquez sur **Orienter** sur un message en file d’attente pour injecter ce suivi dans le tour en cours d’exécution.
|
||||
- Saisissez `/stop` (ou des phrases d’abandon autonomes comme `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`) pour abandonner hors bande.
|
||||
- `chat.abort` prend en charge `{ sessionKey }` (sans `runId`) pour abandonner toutes les exécutions actives de cette session.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Abort partial retention">
|
||||
- Lorsqu’une exécution est abandonnée, le texte partiel de l’assistant peut tout de même être affiché dans l’interface utilisateur.
|
||||
- Le Gateway conserve le texte partiel d’assistant abandonné dans l’historique de transcription lorsqu’une sortie mise en mémoire tampon existe.
|
||||
- Les entrées conservées incluent des métadonnées d’abandon afin que les consommateurs de transcription puissent distinguer les fragments partiels abandonnés de la sortie d’achèvement normale.
|
||||
<Accordion title="Conservation partielle lors d’un abandon">
|
||||
- Lorsqu’une exécution est abandonnée, le texte partiel de l’assistant peut toujours être affiché dans l’interface utilisateur.
|
||||
- Le Gateway conserve dans l’historique de transcription le texte partiel d’assistant abandonné lorsqu’une sortie mise en mémoire tampon existe.
|
||||
- Les entrées conservées incluent des métadonnées d’abandon afin que les consommateurs de transcription puissent distinguer les fragments issus d’un abandon de la sortie d’achèvement normale.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Installation PWA et web push
|
||||
## Installation PWA et Web Push
|
||||
|
||||
L’interface Control fournit un `manifest.webmanifest` et un service worker, ce qui permet aux navigateurs modernes de l’installer comme PWA autonome. Web Push permet au Gateway de réveiller la PWA installée avec des notifications même lorsque l’onglet ou la fenêtre du navigateur n’est pas ouvert.
|
||||
La Control UI fournit un `manifest.webmanifest` et un service worker ; les navigateurs modernes peuvent donc l’installer comme PWA autonome. Web Push permet au Gateway de réveiller la PWA installée avec des notifications même lorsque l’onglet ou la fenêtre du navigateur n’est pas ouvert.
|
||||
|
||||
| Surface | Ce qu’elle fait |
|
||||
| ----------------------------------------------------- | ------------------------------------------------------------------ |
|
||||
| ----------------------------------------------------- | ----------------------------------------------------------------- |
|
||||
| `ui/public/manifest.webmanifest` | Manifeste PWA. Les navigateurs proposent « Installer l’application » une fois qu’il est accessible. |
|
||||
| `ui/public/sw.js` | Service worker qui gère les événements `push` et les clics de notification. |
|
||||
| `push/vapid-keys.json` (sous le répertoire d’état OpenClaw) | Paire de clés VAPID générée automatiquement utilisée pour signer les charges utiles Web Push. |
|
||||
| `push/web-push-subscriptions.json` | Points de terminaison d’abonnement de navigateur conservés. |
|
||||
| `ui/public/sw.js` | Service worker qui gère les événements `push` et les clics sur les notifications. |
|
||||
| `push/vapid-keys.json` (sous le répertoire d’état OpenClaw) | Paire de clés VAPID générée automatiquement pour signer les charges utiles Web Push. |
|
||||
| `push/web-push-subscriptions.json` | Points de terminaison d’abonnement navigateur conservés. |
|
||||
|
||||
Remplacez la paire de clés VAPID via des variables d’environnement sur le processus Gateway lorsque vous voulez épingler les clés (pour les déploiements multi-hôtes, la rotation des secrets ou les tests) :
|
||||
Remplacez la paire de clés VAPID via des variables d’environnement sur le processus Gateway lorsque vous voulez figer les clés (pour les déploiements multi-hôtes, la rotation des secrets ou les tests) :
|
||||
|
||||
- `OPENCLAW_VAPID_PUBLIC_KEY`
|
||||
- `OPENCLAW_VAPID_PRIVATE_KEY`
|
||||
- `OPENCLAW_VAPID_SUBJECT` (par défaut `mailto:openclaw@localhost`)
|
||||
|
||||
L’interface Control utilise ces méthodes Gateway limitées par portée pour enregistrer et tester les abonnements de navigateur :
|
||||
La Control UI utilise ces méthodes Gateway limitées par portée pour enregistrer et tester les abonnements navigateur :
|
||||
|
||||
- `push.web.vapidPublicKey` — récupère la clé publique VAPID active.
|
||||
- `push.web.subscribe` — enregistre un `endpoint` plus `keys.p256dh`/`keys.auth`.
|
||||
@ -218,19 +219,19 @@ L’interface Control utilise ces méthodes Gateway limitées par portée pour e
|
||||
- `push.web.test` — envoie une notification de test à l’abonnement de l’appelant.
|
||||
|
||||
<Note>
|
||||
Web Push est indépendant du chemin relais APNS iOS (voir [Configuration](/fr/gateway/configuration) pour le push adossé à un relais) et de la méthode `push.test` existante, qui ciblent l’appairage mobile natif.
|
||||
Web Push est indépendant du chemin relais iOS APNS (voir [Configuration](/fr/gateway/configuration) pour le push adossé à un relais) et de la méthode `push.test` existante, qui cible l’appairage mobile natif.
|
||||
</Note>
|
||||
|
||||
## Intégrations hébergées
|
||||
|
||||
Les messages d’assistant peuvent afficher du contenu web hébergé en ligne avec le shortcode `[embed ...]`. La politique de sandbox iframe est contrôlée par `gateway.controlUi.embedSandbox` :
|
||||
Les messages d’assistant peuvent afficher du contenu web hébergé en ligne avec le shortcode `[embed ...]`. La politique de sandbox de l’iframe est contrôlée par `gateway.controlUi.embedSandbox` :
|
||||
|
||||
<Tabs>
|
||||
<Tab title="strict">
|
||||
Désactive l’exécution de scripts dans les intégrations hébergées.
|
||||
</Tab>
|
||||
<Tab title="scripts (default)">
|
||||
Autorise les intégrations interactives tout en conservant l’isolation d’origine ; c’est la valeur par défaut et elle suffit généralement pour les jeux/widgets de navigateur autonomes.
|
||||
<Tab title="scripts (par défaut)">
|
||||
Autorise les intégrations interactives tout en conservant l’isolation d’origine ; c’est le comportement par défaut et il suffit généralement pour les jeux/widgets de navigateur autonomes.
|
||||
</Tab>
|
||||
<Tab title="trusted">
|
||||
Ajoute `allow-same-origin` en plus de `allow-scripts` pour les documents du même site qui ont intentionnellement besoin de privilèges plus forts.
|
||||
@ -250,14 +251,14 @@ Exemple :
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Utilisez `trusted` uniquement lorsque le document intégré a réellement besoin du comportement même origine. Pour la plupart des jeux générés par agent et des canevas interactifs, `scripts` est le choix le plus sûr.
|
||||
N’utilisez `trusted` que lorsque le document intégré a réellement besoin d’un comportement same-origin. Pour la plupart des jeux générés par agent et des canevas interactifs, `scripts` est le choix le plus sûr.
|
||||
</Warning>
|
||||
|
||||
Les URL d’intégration externes absolues `http(s)` restent bloquées par défaut. Si vous voulez intentionnellement que `[embed url="https://..."]` charge des pages tierces, définissez `gateway.controlUi.allowExternalEmbedUrls: true`.
|
||||
|
||||
## Largeur des messages de chat
|
||||
|
||||
Les messages de chat groupés utilisent une largeur maximale lisible par défaut. Les déploiements sur grands écrans peuvent la remplacer sans modifier le CSS fourni en définissant `gateway.controlUi.chatMessageMaxWidth` :
|
||||
Les messages de chat groupés utilisent une largeur maximale lisible par défaut. Les déploiements sur écrans larges peuvent la remplacer sans modifier le CSS groupé en définissant `gateway.controlUi.chatMessageMaxWidth` :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -274,8 +275,8 @@ La valeur est validée avant d’atteindre le navigateur. Les valeurs prises en
|
||||
## Accès tailnet (recommandé)
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Integrated Tailscale Serve (preferred)">
|
||||
Gardez le Gateway sur loopback et laissez Tailscale Serve le relayer avec HTTPS :
|
||||
<Tab title="Tailscale Serve intégré (préféré)">
|
||||
Gardez le Gateway sur loopback et laissez Tailscale Serve le proxifier avec HTTPS :
|
||||
|
||||
```bash
|
||||
openclaw gateway --tailscale serve
|
||||
@ -285,16 +286,16 @@ La valeur est validée avant d’atteindre le navigateur. Les valeurs prises en
|
||||
|
||||
- `https://<magicdns>/` (ou votre `gateway.controlUi.basePath` configuré)
|
||||
|
||||
Par défaut, les requêtes Serve de l’interface Control/WebSocket peuvent s’authentifier via les en-têtes d’identité Tailscale (`tailscale-user-login`) lorsque `gateway.auth.allowTailscale` est `true`. OpenClaw vérifie l’identité en résolvant l’adresse `x-forwarded-for` avec `tailscale whois` et en la faisant correspondre à l’en-tête, et n’accepte ces requêtes que lorsqu’elles atteignent loopback avec les en-têtes `x-forwarded-*` de Tailscale. Pour les sessions opérateur de l’interface Control avec identité d’appareil de navigateur, ce chemin Serve vérifié saute également l’aller-retour d’appairage d’appareil ; les navigateurs sans appareil et les connexions de rôle de nœud suivent toujours les vérifications d’appareil normales. Définissez `gateway.auth.allowTailscale: false` si vous voulez exiger des identifiants explicites à secret partagé même pour le trafic Serve. Utilisez ensuite `gateway.auth.mode: "token"` ou `"password"`.
|
||||
Par défaut, les requêtes Control UI/WebSocket Serve peuvent s’authentifier via les en-têtes d’identité Tailscale (`tailscale-user-login`) lorsque `gateway.auth.allowTailscale` vaut `true`. OpenClaw vérifie l’identité en résolvant l’adresse `x-forwarded-for` avec `tailscale whois` et en la faisant correspondre à l’en-tête, et ne les accepte que lorsque la requête atteint loopback avec les en-têtes `x-forwarded-*` de Tailscale. Pour les sessions opérateur Control UI avec identité d’appareil navigateur, ce chemin Serve vérifié saute aussi l’aller-retour d’appairage d’appareil ; les navigateurs sans appareil et les connexions à rôle de nœud suivent toujours les vérifications d’appareil normales. Définissez `gateway.auth.allowTailscale: false` si vous voulez exiger des identifiants explicites à secret partagé même pour le trafic Serve. Utilisez alors `gateway.auth.mode: "token"` ou `"password"`.
|
||||
|
||||
Pour ce chemin d’identité Serve asynchrone, les tentatives d’authentification échouées pour la même IP cliente et la même portée d’authentification sont sérialisées avant les écritures de limitation de débit. Des nouvelles tentatives incorrectes simultanées depuis le même navigateur peuvent donc afficher `retry later` sur la deuxième requête au lieu de deux non-correspondances simples en concurrence parallèle.
|
||||
Pour ce chemin d’identité Serve asynchrone, les tentatives d’authentification échouées pour la même IP cliente et la même portée d’authentification sont sérialisées avant les écritures de limite de débit. Des nouvelles tentatives incorrectes concurrentes depuis le même navigateur peuvent donc afficher `retry later` sur la deuxième requête au lieu de deux simples non-correspondances en concurrence parallèle.
|
||||
|
||||
<Warning>
|
||||
L’authentification Serve sans jeton suppose que l’hôte du Gateway est fiable. Si du code local non fiable peut s’exécuter sur cet hôte, exigez une authentification par jeton/mot de passe.
|
||||
L’authentification Serve sans token suppose que l’hôte du gateway est fiable. Si du code local non fiable peut s’exécuter sur cet hôte, exigez une authentification par token/mot de passe.
|
||||
</Warning>
|
||||
|
||||
</Tab>
|
||||
<Tab title="Bind to tailnet + token">
|
||||
<Tab title="Lier au tailnet + token">
|
||||
```bash
|
||||
openclaw gateway --bind tailnet --token "$(openssl rand -hex 32)"
|
||||
```
|
||||
@ -310,21 +311,21 @@ La valeur est validée avant d’atteindre le navigateur. Les valeurs prises en
|
||||
|
||||
## HTTP non sécurisé
|
||||
|
||||
Si vous ouvrez le tableau de bord via HTTP simple (`http://<lan-ip>` ou `http://<tailscale-ip>`), le navigateur s’exécute dans un **contexte non sécurisé** et bloque WebCrypto. Par défaut, OpenClaw **bloque** les connexions de l’interface Control sans identité d’appareil.
|
||||
Si vous ouvrez le tableau de bord via HTTP simple (`http://<lan-ip>` ou `http://<tailscale-ip>`), le navigateur s’exécute dans un **contexte non sécurisé** et bloque WebCrypto. Par défaut, OpenClaw **bloque** les connexions Control UI sans identité d’appareil.
|
||||
|
||||
Exceptions documentées :
|
||||
|
||||
- compatibilité HTTP non sécurisé limitée à localhost avec `gateway.controlUi.allowInsecureAuth=true`
|
||||
- authentification opérateur réussie de l’interface Control via `gateway.auth.mode: "trusted-proxy"`
|
||||
- authentification Control UI opérateur réussie via `gateway.auth.mode: "trusted-proxy"`
|
||||
- option de dernier recours `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
|
||||
|
||||
**Correctif recommandé :** utilisez HTTPS (Tailscale Serve) ou ouvrez l’interface localement :
|
||||
**Correctif recommandé :** utilisez HTTPS (Tailscale Serve) ou ouvrez l’UI localement :
|
||||
|
||||
- `https://<magicdns>/` (Serve)
|
||||
- `http://127.0.0.1:18789/` (sur l’hôte du Gateway)
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Comportement du basculeur d’authentification non sécurisée">
|
||||
<Accordion title="Comportement du basculement insecure-auth">
|
||||
```json5
|
||||
{
|
||||
gateway: {
|
||||
@ -335,14 +336,14 @@ Exceptions documentées :
|
||||
}
|
||||
```
|
||||
|
||||
`allowInsecureAuth` est uniquement un basculeur de compatibilité locale :
|
||||
`allowInsecureAuth` est uniquement un basculement de compatibilité locale :
|
||||
|
||||
- Il permet aux sessions de l’interface de contrôle localhost de continuer sans identité d’appareil dans des contextes HTTP non sécurisés.
|
||||
- Il permet aux sessions de l’UI de contrôle localhost de continuer sans identité d’appareil dans les contextes HTTP non sécurisés.
|
||||
- Il ne contourne pas les vérifications d’appairage.
|
||||
- Il n’assouplit pas les exigences d’identité d’appareil distant (non-localhost).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Solution d’urgence uniquement">
|
||||
<Accordion title="Break-glass uniquement">
|
||||
```json5
|
||||
{
|
||||
gateway: {
|
||||
@ -354,54 +355,54 @@ Exceptions documentées :
|
||||
```
|
||||
|
||||
<Warning>
|
||||
`dangerouslyDisableDeviceAuth` désactive les vérifications d’identité d’appareil de l’interface de contrôle et constitue une forte dégradation de la sécurité. Rétablissez rapidement le réglage après une utilisation d’urgence.
|
||||
`dangerouslyDisableDeviceAuth` désactive les vérifications d’identité d’appareil de l’UI de contrôle et constitue un affaiblissement de sécurité sévère. Rétablissez rapidement la configuration après l’utilisation d’urgence.
|
||||
</Warning>
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Note sur le proxy de confiance">
|
||||
- Une authentification de proxy de confiance réussie peut autoriser des sessions d’interface de contrôle **opérateur** sans identité d’appareil.
|
||||
- Cela ne s’étend **pas** aux sessions d’interface de contrôle avec rôle de nœud.
|
||||
- Les proxys inverses local loopback sur le même hôte ne satisfont toujours pas l’authentification de proxy de confiance ; consultez [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth).
|
||||
- Une authentification par proxy de confiance réussie peut autoriser des sessions d’UI de contrôle **operator** sans identité d’appareil.
|
||||
- Cela ne s’étend **pas** aux sessions d’UI de contrôle de rôle node.
|
||||
- Les proxys inverses local loopback sur le même hôte ne satisfont toujours pas à l’authentification par proxy de confiance ; consultez [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth).
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
Consultez [Tailscale](/fr/gateway/tailscale) pour les instructions de configuration HTTPS.
|
||||
Consultez [Tailscale](/fr/gateway/tailscale) pour des conseils de configuration HTTPS.
|
||||
|
||||
## Politique de sécurité du contenu
|
||||
|
||||
L’interface de contrôle est livrée avec une politique `img-src` stricte : seuls les ressources de **même origine**, les URL `data:` et les URL `blob:` générées localement sont autorisées. Les URL d’images distantes `http(s)` et relatives au protocole sont rejetées par le navigateur et ne déclenchent aucune requête réseau.
|
||||
L’UI de contrôle est fournie avec une politique `img-src` stricte : seuls les éléments **same-origin**, les URL `data:` et les URL `blob:` générées localement sont autorisés. Les URL d’images distantes `http(s)` et relatives au protocole sont rejetées par le navigateur et ne déclenchent pas de requêtes réseau.
|
||||
|
||||
Ce que cela signifie en pratique :
|
||||
|
||||
- Les avatars et les images servis sous des chemins relatifs (par exemple `/avatars/<id>`) s’affichent toujours, y compris les routes d’avatars authentifiées que l’interface récupère et convertit en URL `blob:` locales.
|
||||
- Les avatars et images servis sous des chemins relatifs (par exemple `/avatars/<id>`) s’affichent toujours, y compris les routes d’avatar authentifiées que l’UI récupère et convertit en URL `blob:` locales.
|
||||
- Les URL inline `data:image/...` s’affichent toujours (utile pour les charges utiles dans le protocole).
|
||||
- Les URL `blob:` locales créées par l’interface de contrôle s’affichent toujours.
|
||||
- Les URL d’avatar distantes émises par les métadonnées de canal sont retirées par les assistants d’avatar de l’interface de contrôle et remplacées par le logo/badge intégré, de sorte qu’un canal compromis ou malveillant ne puisse pas forcer des récupérations d’images distantes arbitraires depuis le navigateur d’un opérateur.
|
||||
- Les URL `blob:` locales créées par l’UI de contrôle s’affichent toujours.
|
||||
- Les URL d’avatar distantes émises par les métadonnées de canal sont supprimées par les assistants d’avatar de l’UI de contrôle et remplacées par le logo/badge intégré, de sorte qu’un canal compromis ou malveillant ne peut pas forcer des récupérations arbitraires d’images distantes depuis le navigateur d’un opérateur.
|
||||
|
||||
Vous n’avez rien à changer pour obtenir ce comportement : il est toujours activé et n’est pas configurable.
|
||||
Vous n’avez rien à modifier pour obtenir ce comportement : il est toujours activé et n’est pas configurable.
|
||||
|
||||
## Authentification de la route d’avatar
|
||||
|
||||
Lorsque l’authentification du Gateway est configurée, le point de terminaison d’avatar de l’interface de contrôle exige le même jeton Gateway que le reste de l’API :
|
||||
Lorsque l’authentification du Gateway est configurée, le point de terminaison d’avatar de l’UI de contrôle exige le même jeton Gateway que le reste de l’API :
|
||||
|
||||
- `GET /avatar/<agentId>` renvoie l’image d’avatar uniquement aux appelants authentifiés. `GET /avatar/<agentId>?meta=1` renvoie les métadonnées de l’avatar selon la même règle.
|
||||
- Les requêtes non authentifiées vers l’une ou l’autre route sont rejetées (comme la route sœur assistant-media). Cela empêche la route d’avatar de divulguer l’identité de l’agent sur des hôtes qui sont autrement protégés.
|
||||
- L’interface de contrôle transmet elle-même le jeton Gateway comme en-tête bearer lors de la récupération des avatars, et utilise des URL blob authentifiées afin que l’image s’affiche toujours dans les tableaux de bord.
|
||||
- `GET /avatar/<agentId>` renvoie l’image d’avatar uniquement aux appelants authentifiés. `GET /avatar/<agentId>?meta=1` renvoie les métadonnées d’avatar selon la même règle.
|
||||
- Les requêtes non authentifiées vers l’une ou l’autre route sont rejetées (comme pour la route sœur assistant-media). Cela empêche la route d’avatar de divulguer l’identité de l’agent sur des hôtes autrement protégés.
|
||||
- L’UI de contrôle transfère elle-même le jeton Gateway comme en-tête bearer lors de la récupération des avatars, et utilise des URL blob authentifiées afin que l’image s’affiche toujours dans les tableaux de bord.
|
||||
|
||||
Si vous désactivez l’authentification du Gateway (non recommandé sur les hôtes partagés), la route d’avatar devient également non authentifiée, conformément au reste du Gateway.
|
||||
|
||||
## Authentification de la route des médias de l’assistant
|
||||
## Authentification de la route média de l’assistant
|
||||
|
||||
Lorsque l’authentification du Gateway est configurée, les aperçus de médias locaux de l’assistant utilisent une route en deux étapes :
|
||||
|
||||
- `GET /__openclaw__/assistant-media?meta=1&source=<path>` exige l’authentification opérateur normale de l’interface de contrôle. Le navigateur envoie le jeton Gateway comme en-tête bearer lors de la vérification de disponibilité.
|
||||
- Les réponses de métadonnées réussies incluent un `mediaTicket` de courte durée limité à ce chemin source exact.
|
||||
- Les URL d’image, d’audio, de vidéo et de document rendues par le navigateur utilisent `mediaTicket=<ticket>` au lieu du jeton Gateway actif ou du mot de passe. Le ticket expire rapidement et ne peut pas autoriser une source différente.
|
||||
- `GET /__openclaw__/assistant-media?meta=1&source=<path>` exige l’authentification operator normale de l’UI de contrôle. Le navigateur envoie le jeton Gateway comme en-tête bearer lors de la vérification de la disponibilité.
|
||||
- Les réponses de métadonnées réussies incluent un `mediaTicket` à courte durée de vie limité à ce chemin source exact.
|
||||
- Les URL d’images, d’audio, de vidéos et de documents rendues par le navigateur utilisent `mediaTicket=<ticket>` au lieu du jeton Gateway actif ou du mot de passe. Le ticket expire rapidement et ne peut pas autoriser une autre source.
|
||||
|
||||
Cela rend le rendu normal des médias compatible avec les éléments multimédias natifs du navigateur sans placer d’identifiants Gateway réutilisables dans des URL de médias visibles.
|
||||
Cela maintient le rendu multimédia normal compatible avec les éléments multimédias natifs du navigateur sans placer d’identifiants Gateway réutilisables dans des URL de média visibles.
|
||||
|
||||
## Construction de l’interface
|
||||
## Construction de l’UI
|
||||
|
||||
Le Gateway sert les fichiers statiques depuis `dist/control-ui`. Construisez-les avec :
|
||||
|
||||
@ -409,7 +410,7 @@ Le Gateway sert les fichiers statiques depuis `dist/control-ui`. Construisez-les
|
||||
pnpm ui:build
|
||||
```
|
||||
|
||||
Base absolue facultative (lorsque vous voulez des URL de ressources fixes) :
|
||||
Base absolue facultative (lorsque vous voulez des URL d’éléments fixes) :
|
||||
|
||||
```bash
|
||||
OPENCLAW_CONTROL_UI_BASE_PATH=/openclaw/ pnpm ui:build
|
||||
@ -421,14 +422,14 @@ Pour le développement local (serveur de développement séparé) :
|
||||
pnpm ui:dev
|
||||
```
|
||||
|
||||
Pointez ensuite l’interface vers votre URL WS du Gateway (par exemple `ws://127.0.0.1:18789`).
|
||||
Pointez ensuite l’UI vers l’URL WS de votre Gateway (par exemple `ws://127.0.0.1:18789`).
|
||||
|
||||
## Débogage/tests : serveur de développement + Gateway distant
|
||||
|
||||
L’interface de contrôle est constituée de fichiers statiques ; la cible WebSocket est configurable et peut être différente de l’origine HTTP. C’est pratique lorsque vous voulez le serveur de développement Vite localement, mais que le Gateway s’exécute ailleurs.
|
||||
L’UI de contrôle est constituée de fichiers statiques ; la cible WebSocket est configurable et peut être différente de l’origine HTTP. C’est pratique lorsque vous voulez le serveur de développement Vite localement, mais que le Gateway s’exécute ailleurs.
|
||||
|
||||
<Steps>
|
||||
<Step title="Démarrer le serveur de développement de l’interface">
|
||||
<Step title="Démarrer le serveur de développement de l’UI">
|
||||
```bash
|
||||
pnpm ui:dev
|
||||
```
|
||||
@ -438,7 +439,7 @@ L’interface de contrôle est constituée de fichiers statiques ; la cible WebS
|
||||
http://localhost:5173/?gatewayUrl=ws%3A%2F%2F<gateway-host>%3A18789
|
||||
```
|
||||
|
||||
Authentification ponctuelle facultative (si nécessaire) :
|
||||
Authentification unique facultative (si nécessaire) :
|
||||
|
||||
```text
|
||||
http://localhost:5173/?gatewayUrl=wss%3A%2F%2F<gateway-host>%3A18789#token=<gateway-token>
|
||||
@ -450,15 +451,15 @@ L’interface de contrôle est constituée de fichiers statiques ; la cible WebS
|
||||
<AccordionGroup>
|
||||
<Accordion title="Notes">
|
||||
- `gatewayUrl` est stocké dans localStorage après le chargement et supprimé de l’URL.
|
||||
- Si vous transmettez un point de terminaison complet `ws://` ou `wss://` via `gatewayUrl`, encodez en URL la valeur `gatewayUrl` afin que le navigateur analyse correctement la chaîne de requête.
|
||||
- `token` doit être transmis via le fragment d’URL (`#token=...`) chaque fois que possible. Les fragments ne sont pas envoyés au serveur, ce qui évite les fuites dans les journaux de requêtes et le Referer. Les paramètres de requête hérités `?token=` sont encore importés une fois par compatibilité, mais uniquement comme solution de repli, et sont supprimés immédiatement après l’amorçage.
|
||||
- Si vous transmettez un point de terminaison `ws://` ou `wss://` complet via `gatewayUrl`, encodez en URL la valeur `gatewayUrl` afin que le navigateur analyse correctement la chaîne de requête.
|
||||
- `token` doit être transmis via le fragment d’URL (`#token=...`) chaque fois que possible. Les fragments ne sont pas envoyés au serveur, ce qui évite les fuites dans les journaux de requêtes et le Referer. Les anciens paramètres de requête `?token=` sont toujours importés une fois pour compatibilité, mais uniquement en solution de repli, et sont supprimés immédiatement après l’amorçage.
|
||||
- `password` est conservé uniquement en mémoire.
|
||||
- Lorsque `gatewayUrl` est défini, l’interface ne se rabat pas sur les identifiants de configuration ou d’environnement. Fournissez explicitement `token` (ou `password`). L’absence d’identifiants explicites est une erreur.
|
||||
- Lorsque `gatewayUrl` est défini, l’UI ne revient pas aux identifiants de configuration ou d’environnement. Fournissez explicitement `token` (ou `password`). L’absence d’identifiants explicites est une erreur.
|
||||
- Utilisez `wss://` lorsque le Gateway est derrière TLS (Tailscale Serve, proxy HTTPS, etc.).
|
||||
- `gatewayUrl` n’est accepté que dans une fenêtre de premier niveau (non intégrée) afin d’empêcher le clickjacking.
|
||||
- Les déploiements non-loopback de l’interface de contrôle doivent définir explicitement `gateway.controlUi.allowedOrigins` (origines complètes). Cela inclut les configurations de développement distantes.
|
||||
- Le démarrage du Gateway peut initialiser des origines locales comme `http://localhost:<port>` et `http://127.0.0.1:<port>` à partir de l’adresse de liaison et du port d’exécution effectifs, mais les origines de navigateurs distants nécessitent toujours des entrées explicites.
|
||||
- N’utilisez pas `gateway.controlUi.allowedOrigins: ["*"]` sauf pour des tests locaux strictement contrôlés. Cela signifie autoriser n’importe quelle origine de navigateur, et non « correspondre à l’hôte que j’utilise ».
|
||||
- `gatewayUrl` n’est accepté que dans une fenêtre de premier niveau (non intégrée) afin d’empêcher le détournement de clic.
|
||||
- Les déploiements non-loopback de l’UI de contrôle doivent définir explicitement `gateway.controlUi.allowedOrigins` (origines complètes). Cela inclut les configurations de développement distantes.
|
||||
- Le démarrage du Gateway peut initialiser des origines locales telles que `http://localhost:<port>` et `http://127.0.0.1:<port>` à partir du bind et du port d’exécution effectifs, mais les origines de navigateur distantes nécessitent toujours des entrées explicites.
|
||||
- N’utilisez pas `gateway.controlUi.allowedOrigins: ["*"]`, sauf pour des tests locaux strictement contrôlés. Cela signifie autoriser toute origine de navigateur, et non « correspondre à l’hôte que j’utilise ».
|
||||
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` active le mode de repli d’origine par en-tête Host, mais c’est un mode de sécurité dangereux.
|
||||
|
||||
</Accordion>
|
||||
@ -478,9 +479,9 @@ Exemple :
|
||||
|
||||
Détails de configuration de l’accès distant : [Accès distant](/fr/gateway/remote).
|
||||
|
||||
## Liens connexes
|
||||
## Connexe
|
||||
|
||||
- [Tableau de bord](/fr/web/dashboard) — tableau de bord du Gateway
|
||||
- [Contrôles d’état](/fr/gateway/health) — surveillance de l’état du Gateway
|
||||
- [TUI](/fr/web/tui) — interface utilisateur en terminal
|
||||
- [WebChat](/fr/web/webchat) — interface de chat dans le navigateur
|
||||
- [Vérifications d’intégrité](/fr/gateway/health) — surveillance de l’intégrité du Gateway
|
||||
- [TUI](/fr/web/tui) — interface utilisateur de terminal
|
||||
- [WebChat](/fr/web/webchat) — interface de chat basée sur le navigateur
|
||||
|
||||
Loading…
Reference in New Issue
Block a user