Update HANDOFF.md: Proxmox TLS and fast-jwt fixes are done

This commit is contained in:
Claude 2026-06-19 10:28:58 +00:00
parent e42853a046
commit 1d1f98f5aa
No known key found for this signature in database

View file

@ -61,7 +61,7 @@ export interface IntegrationAdapter {
|---|---|---|---|
| Docker | `docker.ts` | Pre-existing from an earlier session | Not touched this session |
| Uptime Kuma | `uptimeKuma.ts` | Pre-existing from an earlier session | Not touched this session |
| Proxmox | `proxmox.ts` | Calls `{baseUrl}/api2/json/cluster/resources?type=vm` with a `PVEAPIToken` header; maps VM/CT `status` to health | **Known caveat, not yet fixed**: Proxmox typically uses a self-signed TLS cert by default, and Node's native `fetch` will reject it. No code-level workaround (e.g. a custom `Agent` with `rejectUnauthorized: false`, or documenting that users need a real cert) has been added yet. Flag this to the user if/when someone actually tries to connect a real Proxmox host. |
| Proxmox | `proxmox.ts` | Calls `{baseUrl}/api2/json/cluster/resources?type=vm` with a `PVEAPIToken` header; maps VM/CT `status` to health | Self-signed TLS certs (Proxmox's default) are explicitly allowed — requests go through an `undici` `Agent` with `rejectUnauthorized: false` set as the fetch `dispatcher`. Fixed in a follow-up session. |
| NetBird | `netbird.ts` | Calls NetBird Management API `/api/peers` with a `Token` bearer header; defaults to `https://api.netbird.io` but respects `config.baseUrl` for self-hosted management servers; maps peer `connected` bool to healthy/critical | Verified against the real NetBird Cloud API (got a real 403 with a fake token, confirming live wiring) |
| Cloudflare | `cloudflare.ts` | Calls `/client/v4/zones/{zoneId}` with a Bearer token; reports zone `status` as health | **Bug fixed this session**: originally called `res.json()` before checking `res.ok`, but Cloudflare returns plain-text bodies for some error cases, causing a JSON-parse crash. Fixed by checking `res.ok` immediately after `fetch()`. |
| AWS | `aws.ts` | Uses `@aws-sdk/client-sts` (`GetCallerIdentityCommand`) for connection test, `@aws-sdk/client-ec2` (`DescribeInstancesCommand`) for resource listing; maps EC2 instance state to health, uses the `Name` tag (fallback to instance ID) for resource naming | New deps: `@aws-sdk/client-sts`, `@aws-sdk/client-ec2` (already in `backend/package.json`). User said they'll create a dedicated least-privilege IAM user for this in production — not yet done, just code-ready. |
@ -91,10 +91,10 @@ No system `sshd` was available in the sandbox (`apt-get install openssh-server`
## Things explicitly NOT done / open for follow-up (not yet actioned, no decision made)
1. **Proxmox self-signed TLS cert handling** — Node's `fetch` will reject Proxmox's default cert. No workaround added.
2. **`fast-jwt` vulnerability** — `@fastify/jwt` has a known critical transitive vuln in the version currently pinned; fixing it requires bumping to `@fastify/jwt` v10, which is a breaking change per npm's own advisory. Not attempted — needs a deliberate decision with the user since it could break auth.
3. **SSH private-key textarea UX** — see above, the single-line input may mishandle multi-line PEM keys.
4. **`/terminal` page** — entirely on hold, pending a separate Termix-fork integration the user is handing to another AI session. **Do not start this.**
1. ~~Proxmox self-signed TLS cert handling~~**done**, see adapter table above.
2. ~~`fast-jwt` vulnerability~~**done**: bumped `@fastify/jwt` to v10 (pulls in patched `fast-jwt`), `npm audit` now reports 0 vulnerabilities in `backend/`. Verified auth still works (setup, valid token, rejected bad token) after the bump.
3. **SSH private-key textarea UX** — see above, the single-line input may mishandle multi-line PEM keys. Not yet fixed.
4. **`/terminal` page** — entirely on hold, pending a separate Termix-fork integration the user is handing to another AI session. **Do not start this without the user explicitly confirming it's time.**
5. Registry/route enum duplication (`IntegrationType` vs. `integrationTypes` in routes/integrations.ts) — works correctly now but is a latent footgun for future integration types. Worth a refactor sometime, not urgent.
## Quick orientation for a new session