mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-20 05:42:19 +03:00
5ca724d2cf
Merged after reconciling the whole stack onto the tip, operator-reviewed before merge. The core ownership fix for GHSA-wvxc-jp3v-5mg5 had already landed via #13211 with a different implementation of the same endpoint. This branch carries a stricter one, built up in layers: this PR, #13262 (explicit scope, audit log, atomic sweep), #13297 (revoked, deactivated, banned or expired keys rejected) and #13374 (owner-scoped file half, chunked instance sweep — SEC-C/SEC-D). The stack's implementation was kept over #13211's because it is stricter on every point: - **route:** with #13211, a request carrying BOTH a dashboard session cookie and an API key swept the whole instance. Here a presented key always scopes the sweep to that key; only a session without a key sweeps all tenants; neither returns 401. Instance-wide and row-deleting sweeps log at warn as an audit trail, and a failing sweep returns a sanitized 500. - **`deleteCompletedBatches`:** takes an explicit `{ apiKeyId } | { allTenants: true }`. An omitted or blank key throws instead of widening, and passing both throws. - **files:** a key sweep only soft-deletes files the caller owns (`deleteFileOwnedBy`), so a batch referencing another tenant's or an unowned file never nulls its content. - **transactions:** key mode is all-or-nothing across chunks; instance mode commits per 200-id chunk so a large sweep never holds one write lock on the table. #13211's own test was aligned to the explicit-scope API with its assertions unchanged. Its seed now creates the file with the batch's owner, as an upload through that key does in production — without that, SEC-C correctly leaves the unowned file intact. - 51/51 across the six batch suites (#13211's test, this stack's ownership and route-scope tests, `batch-deletion`, `batch-deletion-route-logic`, `files-delete-owned-by`) - ESLint, `typecheck:core`, complexity, cognitive-complexity, changelog integrity: clean ⚠️ base-red inherited: #12732
changelog.d/ — changelog fragments
A PR never edits CHANGELOG.md directly during the cycle. Instead it adds ONE new
file here — its changelog entry as a fragment. Two PRs never touch the same file, so
changelog merge conflicts (the "CHANGELOG-eat" cascade that forced a re-sync push + full
CI re-run after every sibling merge) are structurally impossible.
Convention
| Directory | Aggregates under |
|---|---|
features/ |
### ✨ New Features |
fixes/ |
### 🐛 Bug Fixes |
maintenance/ |
### 📝 Maintenance |
- Filename:
<PR-number>-<short-slug>.md(e.g.fixes/6700-dockerfile-better-sqlite3.md). The PR number prefix keeps aggregation order deterministic. - Content: the exact bullet line(s) that should land in
CHANGELOG.md, starting with-. Multi-line (continuation) bullets are fine. Keep the repo's credit format:(#PR — thanks @user). - One fragment per PR (rarely more, e.g. a PR that both fixes and adds).
Example
changelog.d/fixes/6496-cloudflare-relay-worker-syntax.md:
- **fix(providers):** Cloudflare relay Worker deploys use Service Worker syntax with `body_part` metadata ([#6496](https://github.com/diegosouzapw/OmniRoute/pull/6496)) — thanks @SeaXen
Aggregation
The release captain (or /generate-release) folds all fragments into CHANGELOG.md and
deletes them:
node scripts/release/aggregate-changelog.mjs # write + delete fragments
node scripts/release/aggregate-changelog.mjs --dry-run # preview only
Fragment well-formedness is enforced by npm run check:changelog-integrity (the same
gate that guards against CHANGELOG-eat for legacy direct edits).