Plugin guides
Plugin RPC HTTP d’administration
Le plugin intégré admin-http-rpc expose via HTTP un ensemble autorisé de méthodes du plan de contrôle du Gateway, pour les automatisations d’hôte de confiance qui ne peuvent pas maintenir ouverte une connexion WebSocket au Gateway.
Il est fourni avec OpenClaw, mais désactivé par défaut ; lorsqu’il est désactivé, la route n’est pas enregistrée. Lorsqu’il est activé, il ajoute POST /api/v1/admin/rpc sur le même point d’écoute que le Gateway (http://<gateway-host>:<port>/api/v1/admin/rpc).
Activez-le uniquement pour des outils privés de l’hôte, des automatisations du tailnet ou un point d’entrée interne de confiance. N’exposez jamais cette route directement à l’Internet public.
Avant de l’activer
La RPC HTTP d’administration constitue une surface complète du plan de contrôle pour les opérateurs : tout appelant qui réussit l’authentification HTTP du Gateway peut invoquer les méthodes autorisées ci-dessous. Activez-la uniquement si toutes les conditions suivantes sont remplies :
- L’appelant est autorisé à administrer le Gateway.
- L’appelant ne peut pas utiliser le client RPC WebSocket.
- La route est accessible uniquement via local loopback, un tailnet ou un point d’entrée privé authentifié.
- Vous avez vérifié les méthodes autorisées et elles correspondent à l’automatisation que vous prévoyez d’exécuter.
Pour les clients OpenClaw et les outils interactifs capables de maintenir ouverte une connexion WebSocket au Gateway, utilisez plutôt la RPC WebSocket.
Activation
Activez le plugin intégré :
CLI
openclaw plugins enable admin-http-rpcopenclaw gateway restartConfiguration
{ plugins: { entries: { "admin-http-rpc": { enabled: true }, }, },}La route est enregistrée au démarrage du plugin ; redémarrez donc le Gateway après avoir modifié la configuration du plugin.
Désactivez-le lorsque vous n’avez plus besoin de la surface HTTP :
openclaw plugins disable admin-http-rpcopenclaw gateway restartVérification de la route
Utilisez health comme requête sûre minimale :
curl -sS http://<gateway-host>:<port>/api/v1/admin/rpc \ -H 'Authorization: Bearer <gateway-token>' \ -H 'Content-Type: application/json' \ -d '{"method":"health","params":{}}'Une réponse réussie contient ok: true :
{ "id": "generated-request-id", "ok": true, "payload": { "status": "ok" }}Lorsque le plugin est désactivé, la route renvoie 404, car elle n’est pas enregistrée.
Authentification
La route du plugin utilise l’authentification HTTP du Gateway.
Méthodes d’authentification courantes :
- authentification par secret partagé (
gateway.auth.mode="token"ou"password") :Authorization: Bearer <token-or-password> - authentification HTTP de confiance porteuse d’identité (
gateway.auth.mode="trusted-proxy") : faites transiter la requête par le proxy configuré tenant compte de l’identité et laissez-le injecter les en-têtes d’identité requis - authentification ouverte sur un point d’entrée privé (
gateway.auth.mode="none") : aucun en-tête d’authentification requis
Modèle de sécurité
Considérez ce plugin comme une surface opérateur complète du Gateway.
- L’activation du plugin donne intentionnellement accès aux méthodes RPC d’administration autorisées sur
/api/v1/admin/rpc. - Le plugin déclare le contrat de manifeste réservé
contracts.gatewayMethodDispatch: ["authenticated-request"], qui permet à sa route HTTP authentifiée par le Gateway de distribuer les méthodes du plan de contrôle dans le processus. Il ne s’agit pas d’un bac à sable : le contrat empêche l’utilisation accidentelle des assistants réservés du SDK, mais les plugins de confiance s’exécutent toujours dans le processus du Gateway. - L’authentification par porteur d’un secret partagé (modes
token/password) prouve la possession du secret de l’opérateur du Gateway ; les en-têtesx-openclaw-scopesplus restrictifs sont ignorés sur ce chemin et les autorisations complètes par défaut de l’opérateur sont rétablies. - L’authentification HTTP de confiance porteuse d’identité (mode
trusted-proxy) respectex-openclaw-scopeslorsqu’il est présent. gateway.auth.mode="none"signifie que cette route n’est pas authentifiée si le plugin est activé. Utilisez ce mode uniquement derrière un point d’entrée privé auquel vous faites entièrement confiance.- Une fois l’authentification de la route du plugin réussie, les requêtes sont distribuées par les mêmes gestionnaires de méthodes et contrôles de portée du Gateway que la RPC WebSocket.
- La route reste accessible pendant un bail de suspension préparé. La validation bornée des requêtes et la réponse locale de découverte
commands.listrestent disponibles. Parmi les méthodes distribuées au Gateway, seulesgateway.suspend.prepare,gateway.suspend.statusetgateway.suspend.resumepeuvent s’exécuter lorsque l’admission est fermée ; les autres méthodes autorisées renvoient la réponse réessayable habituelleUNAVAILABLEdu Gateway. - Limitez cette route à local loopback, au tailnet ou à un point d’entrée privé de confiance. Ne l’exposez pas directement à l’Internet public. Utilisez des gateways distincts lorsque les appelants franchissent des limites de confiance.
Requête
POST /api/v1/admin/rpcAuthorization: Bearer <gateway-token>Content-Type: application/json{ "id": "optional-request-id", "method": "health", "params": {}}Champs :
id(chaîne, facultatif) : copié dans la réponse. Un UUID est généré en cas d’omission.method(chaîne, obligatoire) : nom d’une méthode autorisée du Gateway.params(type quelconque, facultatif) : paramètres propres à la méthode.
La taille maximale par défaut du corps de la requête est de 1 Mo.
Réponse
Les réponses réussies utilisent la structure RPC du Gateway :
{ "id": "optional-request-id", "ok": true, "payload": {}}Les erreurs de méthode du Gateway utilisent :
{ "id": "optional-request-id", "ok": false, "error": { "code": "INVALID_REQUEST", "message": "bad params" }}Le statut HTTP dépend du code d’erreur :
| Code d’erreur | Statut HTTP |
|---|---|
INVALID_REQUEST |
400 |
APPROVAL_NOT_FOUND |
404 |
NOT_LINKED, NOT_PAIRED |
409 |
UNAVAILABLE |
503 |
AGENT_TIMEOUT |
504 |
| tout autre code | 500 |
Méthodes autorisées
- découverte :
commands.listRenvoie les noms des méthodes RPC HTTP autorisées par ce plugin. - Gateway :
health,status,logs.tail,usage.status,usage.cost,gateway.restart.request,gateway.suspend.prepare,gateway.suspend.status,gateway.suspend.resume - configuration :
config.get,config.schema,config.schema.lookup,config.set,config.patch,config.apply - canaux :
channels.status,channels.start,channels.stop,channels.logout - Web :
web.login.start,web.login.wait - modèles :
models.list,models.authStatus - agents :
agents.list,agents.create,agents.update,agents.delete - approbations :
exec.approvals.get,exec.approvals.set,exec.approvals.node.get,exec.approvals.node.set - Cron :
cron.status,cron.list,cron.get,cron.runs,cron.add,cron.update,cron.remove,cron.run - appareils :
device.pair.list,device.pair.approve,device.pair.reject,device.pair.remove - Nodes :
node.list,node.describe,node.pair.list,node.pair.approve,node.pair.reject,node.pair.remove,node.rename - tâches :
tasks.list,tasks.get,tasks.cancel - diagnostics :
doctor.memory.status,update.status
Les autres méthodes du Gateway sont bloquées tant qu’elles ne sont pas ajoutées intentionnellement.
Comparaison avec WebSocket
Le chemin RPC WebSocket normal du Gateway reste l’API de plan de contrôle privilégiée pour les clients OpenClaw. Utilisez la RPC HTTP d’administration uniquement pour les outils de l’hôte nécessitant une surface HTTP de type requête-réponse.
Les clients WebSocket utilisant un jeton partagé et dépourvus d’une identité d’appareil de confiance ne peuvent pas déclarer eux-mêmes des portées d’administration lors de la connexion. La RPC HTTP d’administration suit délibérément le modèle d’opérateur HTTP de confiance existant : lorsque le plugin est activé, l’authentification par porteur d’un secret partagé est considérée comme un accès opérateur complet à cette surface d’administration.
Dépannage
404 Not Found
: Le plugin est désactivé, le Gateway n’a pas été redémarré depuis son activation ou la requête est envoyée à un autre processus du Gateway.
401 Unauthorized
: La requête n’a pas satisfait à l’authentification HTTP du Gateway. Vérifiez le jeton porteur ou les en-têtes d’identité du proxy de confiance.
405 Method Not Allowed
: La requête a utilisé une méthode autre que POST.
413 Payload Too Large
: Le corps de la requête a dépassé la limite de 1 Mo.
400 INVALID_REQUEST
: Le corps de la requête n’est pas un JSON valide, le champ method est absent, la méthode ne figure pas dans la liste autorisée du plugin ou l’identifiant de reprise de suspension ne correspond pas au bail actif.
503 UNAVAILABLE
: La méthode du Gateway est en cours de démarrage, limitée en débit, suspendue ou en attente d’une opération concurrente de suspension ou de reprise. Consultez error.details lorsqu’il est présent et respectez error.retryAfterMs avant de réessayer.