fix(accounts-base): gate /_accounts/cookie/* endpoints behind useHttpOnlyCookies and cap /set body size - #14657
fix(accounts-base): gate /_accounts/cookie/* endpoints behind useHttpOnlyCookies and cap /set body size#14657italojs wants to merge 2 commits into
Conversation
… cap /set body size (#14654) The HttpOnly cookie endpoints (set/refresh/clear) were mounted unconditionally at package load, exposing three unauthenticated HTTP paths on every Meteor 3.5+ server even when the app never enabled useHttpOnlyCookies. The /set endpoint also buffered the entire request body in memory before validating it. Handlers now fall through to the app's own routing unless the feature is enabled — via Accounts.config({ useHttpOnlyCookies: true }) on the server or Meteor.settings.public.packages.accounts.useHttpOnlyCookies. The check happens per request because Accounts.config typically runs inside Meteor.startup, after the handlers are registered. readJson now rejects bodies larger than 4 KB (checked against Content-Length up front and enforced while streaming), returning 413. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for v3-meteor-api-docs canceled.
|
✅ Deploy Preview for v3-migration-docs canceled.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe HTTP-only cookie endpoints now use opt-in configuration gating. ChangesHTTP-only cookie controls
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/accounts-base/accounts_cookie_server_tests.js`:
- Around line 228-229: Update the assertion for refreshRes in the
disabled-refresh test to require the specific status returned by the downstream
unhandled-route handler, rather than merely checking that it is not 204.
Preserve the existing GET request through REFRESH_PATH and use the test app’s
known fall-through status.
In `@packages/accounts-base/server_http_cookies.js`:
- Around line 75-82: Update the request-size check in the data handler around
req.setEncoding and MAX_JSON_BODY_BYTES to measure the accumulated body’s UTF-8
byte length rather than JavaScript string length. Preserve the existing pause,
reset, and settle behavior when the byte limit is exceeded.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: cf8430fc-f0e4-47f9-af68-d17bdf3071f0
📒 Files selected for processing (2)
packages/accounts-base/accounts_cookie_server_tests.jspackages/accounts-base/server_http_cookies.js
… test String.length counts UTF-16 code units, so a body of multi-byte characters could exceed the 4 KB limit while passing the check. readJson now accumulates raw buffers and counts actual bytes. The disabled-endpoints test now also asserts the refresh response is not application/json, proving the request fell through to the app stack instead of merely not being a 204. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fixes #14654
Since accounts-base 3.3.0 (Meteor 3.5), the HttpOnly cookie endpoints —
POST /_accounts/cookie/set,GET /_accounts/cookie/refresh,POST /_accounts/cookie/clear— are mounted on every server, even when the app never enableduseHttpOnlyCookies./setalso buffered the entire request body in memory before validating it.Changes
next()) unless the feature is enabled, so by default the routes behave as if they were never mounted. Both documented opt-ins count:Accounts.config({ useHttpOnlyCookies: true })on the server andMeteor.settings.public.packages.accounts.useHttpOnlyCookies. The check runs per request becauseAccounts.configusually runs inMeteor.startup, after the handlers are registered./setbody is now capped at 4 KB — rejected viaContent-Lengthup front and enforced while streaming — returning413 {"error":"body_too_large"}.Note: enabling the feature only on the client used to work by accident (the endpoints were always live). It now requires the documented server-side opt-in.
Verification
Repro: https://github.com/italojs/meteor-issue-repros/tree/issue-14654 (stock 3.5.1 minimal app + accounts-base)
/setis fully buffered before the 400.accounts cookietinytests pass, including 3 new ones (413 via streaming, 413 via Content-Length, fall-through when disabled). Two client-side DDP login tests failed with the rate limiter'stoo-many-requests— a login-flow flake unrelated to these HTTP handlers.Summary by CodeRabbit
New Features
Bug Fixes