mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-31 19:16:29 +00:00
37d0766ba5
Follow-up hardening on the request-id grant path. approve_request took the same lockout treatment as approve_code: gated by it, and recording a miss toward it. But the two paths defend different things. The lockout exists to stop guessing at the 8-char code space over a messaging channel; a request id is only ever obtained by an admin already authenticated to the store, so a miss means the row they clicked went stale. Counting those let a handful of clicks on a stale list lock the operator out of `hermes pairing approve` for an hour — the GUI DoSing the CLI. Also drops the `code`/`code_hash_prefix` compat fields from list_pending. The hash prefix is what admin surfaces mistook for an approvable code in the first place, and re-exporting the request id under the old `code` key just preserves the ambiguity; both consumers in the tree read `request_id` now. The 16-hex sniffing that had been copy-pasted into the CLI and the endpoint (where a chained conditional consulted it against the wrong field) moves to one owner, PairingStore.looks_like_request_id. The endpoint no longer reports a 429 on the request-id path, where lockout can't apply — a stale id surfaced as a bogus "locked out" while the platform sat locked for something else entirely. |
||
|---|---|---|
| .. | ||
| AnalyticsPage.tsx | ||
| ChannelsPage.tsx | ||
| ChatPage.tsx | ||
| ConfigPage.tsx | ||
| CronPage.tsx | ||
| DocsPage.tsx | ||
| EnvPage.tsx | ||
| FilesPage.tsx | ||
| LogsPage.tsx | ||
| McpPage.tsx | ||
| ModelsPage.tsx | ||
| PairingPage.tsx | ||
| PluginsPage.tsx | ||
| ProfileBuilderPage.tsx | ||
| ProfilesPage.tsx | ||
| SessionsPage.tsx | ||
| SkillsPage.tsx | ||
| SystemPage.tsx | ||
| WebhooksPage.tsx | ||