DELETE /v1/org/{orgId} on the Integration API always returned
500 "An error occurred..." and left the organization in place, even for a
root API key holding the deleteOrg action. The handler looked up the
caller's ownership with req.user!.userId, but Integration API requests are
authenticated by verifyApiKey, which sets req.apiKey and never req.user,
so the lookup threw "Cannot read properties of undefined (reading
'userId')".
#1376 was fixed in f37eda47 by dropping the user-only permission check;
79cf7c84 later added the owner check to the handler shared by both
routers, reintroducing the failure for API keys.
Keep the owner check for dashboard sessions. For Integration API keys the
route is already restricted by verifyApiKeyIsRoot and
verifyApiKeyHasAction(deleteOrg), so load the organization directly. Both
paths still refuse a billing organization and return the same 404 for an
unknown organization.
Verified against a local SQLite instance with a root key: before the
change, create returned 201 and delete returned 500 with the organization
still present; after it, delete returns 200 and a repeated delete or GET
returns 404. npx tsc --noEmit passes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolves#1408.
A rule with match "METHOD" carries a comma-separated list of HTTP
methods in its value, e.g. "POST,PUT", and applies when the request
method is in that list. This makes it possible to leave GET public
while sending POST and PUT to auth, which rules could not express
before because both share the same path.
No new columns: the methods live in the existing rule value, so this
needs no migration and every existing rule keeps working unchanged.
The UI offers the ten registered methods. Blueprints and the API
accept any method token, so extension methods such as the WebDAV verbs
can be targeted too, and the UI preserves them when a rule set that
way is edited later.
Owen Schwartz