- Use 'brew upgrade node@22 || brew install node@22' so existing older Node is upgraded
- Add node@22 bin to PATH after install so node/npm are found
- Align error message with node@22 (was suggesting node@22 while install used node)
Made-with: Cursor
The optional variant of get_agent_auth_context had accept_authorization=False,
which prevented agents using Authorization: Bearer from passing through the
ACTOR_DEP / BOARD_READ_DEP / TASK_DEP dependency chain.
This caused 401 on any agent route that resolves a board or task via the shared
ACTOR_DEP (e.g. PATCH /agent/boards/{id}/tasks/{id} and
POST /agent/boards/{id}/tasks/{id}/comments), even though the same token worked
fine on routes that use AGENT_CTX_DEP directly (accept_authorization=True).
Fix: set accept_authorization=True in get_agent_auth_context_optional so both
X-Agent-Token and Authorization: Bearer are accepted consistently.
Verified: PATCH and POST /comments now resolve board/task correctly when
Authorization: Bearer is used. No security regression — agent_token_hash
comparison rejects any non-agent bearer tokens.
FastAPI 0.131.0 includes Pydantic's Rust-based JSON serialization by default (PR #14962), making ORJSONResponse unnecessary. The new default serialization is 2x faster than the previous approach and eliminates the need for explicit orjson configuration.
Changes:
- Upgrade FastAPI from 0.130.0 to 0.131.0
- Remove orjson dependency (deprecated in 0.131.0)
- Remove ORJSONResponse import and configuration
- Use FastAPI's new default Pydantic-based serialization
Co-authored-by: abhi1693 <5083532+abhi1693@users.noreply.github.com>
- Add healthcheck to Redis service in compose.yml and upgrade
depends_on from service_started to service_healthy so backend
and webhook-worker wait for Redis readiness.
- Add HTTP security headers middleware (X-Content-Type-Options,
X-Frame-Options, Referrer-Policy, Permissions-Policy) to the
FastAPI backend.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous fix fell back to the scheme's default port (443/80) when
url.port was empty, but url.port is empty for *both* 'wss://host:443'
and 'wss://host' — causing the validation to wrongly accept a URL with
no port at all.
Fix: inspect the raw authority segment of the URL string to check
whether a ':port' component is actually present, regardless of whether
that port is the scheme default.
Add gateway-form.test.ts covering:
- explicit non-default ports (accepted)
- explicit default ports :443 / :80 (accepted — regression case)
- missing port (rejected)
- wrong scheme (rejected)
- invalid URL (rejected)
- whitespace trimming
Closes#148
