fix(workflows): harden workflow API auth routes

[PlaneInABottle]

Summary

• Hardens workflow lifecycle and deployment auth after the rebase so session, API-key, and internal callers follow the same access path.
• Incorporates the latest landed fixes already on the branch: rebased auth-hardening updates, the env mock fix, the duplicate lookup fix, and the archived workspace access fix.
• Also includes the current follow-up scope in the worktree: API-key audit actor metadata on lifecycle routes, deployment activation reuse of the preloaded workflow, and an English docs clarification.

What changed

• Landed on the branch
  • Rebases and keeps the workflow API auth-hardening stack aligned with current staging
  • Preserves env mocks / workflow context in the affected workflow route tests to avoid rebase regressions
  • Fixes the duplicate lookup path introduced in the hardened workflow access flow
  • Blocks archived workspace access for workflow routes
• Current follow-up in the worktree
  • Carries API-key actor name / email into deploy, activate, and revert audit records
  • Reuses the already loaded workflow during deployment activation auth checks instead of performing another lookup
  • Clarifies the English execution API docs to note that lifecycle/deployment endpoints can also be used with session auth or API keys where supported

Validation

• Targeted workflow auth coverage has been expanded across middleware, deploy, deployment activation, deployment revert, status, and async execution paths
• Follow-up test updates cover API-key audit actor metadata and preloaded-workflow reuse in deployment activation
• Docs change is wording-only and does not change runtime behavior

[cursor]

PR Summary

Medium Risk
Touches workflow lifecycle/deployment auth and rollback paths; while changes are mostly refactors and added guardrails, they can affect access control decisions and deployment behavior if the new middleware semantics diverge from prior expectations.

Overview
Hardens workflow lifecycle and deployment APIs to use a single hybrid access path across session, API-key, and internal callers via an expanded validateWorkflowAccess (supports action and requireDeployment options, workspace-scoped API key validation, and optional internal-secret bypass).

Improves deployment reliability and auditing: deploy now preserves prior deployedAt on rollback, deletes failed deployment versions, and treats MCP sync/webhook cleanup as non-fatal (logged but still returns success). Audit logging now consistently records API-key actor name/email via getAuditActorMetadata.

Updates revert-to-deployment to restore draft state (including variables) in a transaction, adds broader test coverage for auth/JSON parsing/error cases across deploy/activate/revert/deployed/status routes, and clarifies docs that lifecycle/deployment endpoints can be used with session auth or API keys where supported.

^{Written by Cursor Bugbot for commit 0981aaa. This will update automatically on new commits. Configure here.}

[vercel]

Someone is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR hardens the workflow API auth layer by introducing a shared validateWorkflowAccess middleware and migrating seven route surfaces ([id], deploy, deployed, status, deployments, deployments/[version], deployments/[version]/revert) onto it, replacing a patchwork of session-only and ad-hoc auth checks with a consistent session / API-key / internal-secret path.

Key observations:

• The overall direction is correct and the standardisation is a genuine improvement over the previous divergent per-route auth.
• Double authorization in route.ts: Both the DELETE and PUT handlers call validateWorkflowAccess (which internally runs authorizeWorkflowByWorkspacePermission) and then immediately call authorizeWorkflowByWorkspacePermission a second time with the same arguments. The redundant second call wastes a DB round-trip on every request and introduces a small race-condition window where the two checks could return different results.
• Double session validation in deploy/route.ts: validateLifecycleAdminAccess calls validateWorkflowAccess for all callers (which already completes auth + permission checks for session users), and then, for session callers, discards the result and re-runs validateWorkflowPermissions in full. The first check's result is silently thrown away for this auth type.
• Dead allowInternalSecret: false option in deployed/route.ts: The allowInternalSecret field is only evaluated inside the requireDeployment: true code path in middleware. Specifying it with requireDeployment: false has no effect and misleads readers.
• The allowInternalSecret default in middleware.ts is coupled to requireDeployment unnecessarily, which reinforces the same misunderstanding.
• Test coverage is good — every changed route has a corresponding test file, and the tests verify the new middleware is called with the expected options.

Confidence Score: 3/5

• Auth hardening direction is correct but two routes contain redundant/double authorization logic that should be resolved before merging.
• The shared middleware and its adoption across routes is well-structured, and the test suite covers the new paths. However, the double authorizeWorkflowByWorkspacePermission in the [id] route and the double session-validation in the deploy route are real logic issues that add unnecessary DB load and create subtle race-condition windows in security-critical code paths.
• apps/sim/app/api/workflows/[id]/route.ts (DELETE/PUT double authorization) and apps/sim/app/api/workflows/[id]/deploy/route.ts (double session validation in validateLifecycleAdminAccess).

Important Files Changed

Filename	Overview
apps/sim/app/api/workflows/middleware.ts	New centralized validateWorkflowAccess function with good structure; the allowInternalSecret default coupling to requireDeployment is misleading and should be cleaned up.
apps/sim/app/api/workflows/[id]/route.ts	DELETE and PUT handlers perform a redundant second authorizeWorkflowByWorkspacePermission call after validateWorkflowAccess already authorized the user, creating unnecessary DB round-trips and a race-condition window.
apps/sim/app/api/workflows/[id]/deploy/route.ts	Session-authenticated callers are double-validated: validateWorkflowAccess completes auth and permission checks, then validateLifecycleAdminAccess discards the result and re-runs validateWorkflowPermissions for session users.
apps/sim/app/api/workflows/[id]/deployed/route.ts	Clean internal-caller bypass with JWT verification; the allowInternalSecret: false option passed to validateWorkflowAccess is dead code and should be removed.
apps/sim/app/api/workflows/[id]/status/route.ts	Clean migration to shared validateWorkflowAccess; no issues found.
apps/sim/app/api/workflows/[id]/deployments/route.ts	Straightforward use of shared middleware for deployment list read access; no issues found.
apps/sim/app/api/workflows/[id]/deployments/[version]/route.ts	Good use of per-action permission escalation (read vs admin for activation); validateDeploymentVersionLifecycleAccess wrapper is clean but slightly redundant given it only forwards to validateWorkflowAccess unchanged.
apps/sim/app/api/workflows/[id]/deployments/[version]/revert/route.ts	Clean admin-only guard via shared middleware; actor identity checked before mutation; no issues found.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Request] --> B{Auth Type?}

    B -->|Bearer JWT| C[verifyInternalToken\ndeployed/route only]
    C -->|valid| D[Skip validateWorkflowAccess\nload deployed state directly]
    C -->|invalid| E[validateWorkflowAccess]

    B -->|Session / API Key / Internal Secret| E

    E --> F[getWorkflowById]
    F -->|not found| G[404 Workflow not found]
    F -->|found, no workspaceId| H[403 Personal workflow deprecated]

    F -->|requireDeployment: false| I[checkHybridAuth]
    I -->|fail / no userId| J[401 Unauthorized]
    I -->|success + userId| K[authorizeWorkflowByWorkspacePermission\naction: read / write / admin]
    K -->|denied| L[403 / 404 Access denied]
    K -->|allowed| M[Return workflow + auth]

    F -->|requireDeployment: true| N{isDeployed?}
    N -->|false| O[403 Workflow not deployed]
    N -->|true| P{Internal Secret header?}
    P -->|valid + allowInternalSecret| Q[Return workflow — no userId]
    P -->|missing / invalid| R[Check X-Api-Key header]
    R -->|missing| S[401 API key required]
    R -->|present| T[authenticateApiKeyFromHeader\nworkspace or personal]
    T -->|fail| U[401 Invalid API key]
    T -->|success| V[updateApiKeyLastUsed\nReturn workflow]

    M --> W[Route handler\nDELETE / PUT / POST / PATCH / GET]
    V --> W
    Q --> W

Loading

Comments Outside Diff (1)

1. apps/sim/app/api/workflows/[id]/route.ts, line 170-192 (link)

   Redundant double authorization check

   validateWorkflowAccess at line 150 already calls checkHybridAuth followed by authorizeWorkflowByWorkspacePermission with the same action: 'admin'. If that first check passes, the userId is guaranteed to have workspace admin permission. Re-running authorizeWorkflowByWorkspacePermission here with the same userId and action creates:

   1. A redundant DB round-trip on every request.
   2. A window for a race condition — if the workspace membership changes between the two calls, the second check could return a different result, leading to inconsistent behaviour (e.g. the first check passes but the second returns authorization.allowed = false, causing a 403 even though the user was legitimately authorised).

   The workflow object is already available via validation.workflow and the access is already verified, so the second authorizeWorkflowByWorkspacePermission call (and the canDelete guard that depends on it) should be removed in favour of using validation.workflow directly:

   const workflowData = validation.workflow
   if (!workflowData) {
     return NextResponse.json({ error: 'Workflow not found' }, { status: 404 })
   }
   

   The same pattern applies to the PUT handler at lines 403–424.

_{Last reviewed commit: 73c1328}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 19, 2026 0:32am

[icecrasher321]

@PlaneInABottle this PR might have to wait till our v0.6 release. Lot of auth changes there that might overwrite this potentially

[icecrasher321]

@PlaneInABottle can you rebase against staging

[icecrasher321]

bugbot run

[cursor]

Deploy PATCH uses admin instead of write for initial access

Medium Severity

The PATCH handler for the deploy route (toggle isPublicApi) calls validateWorkflowAccess with action: 'admin', but this endpoint only updates a boolean flag on the workflow record. The previous code used validateWorkflowPermissions(id, requestId, 'admin') which was session-only, but now that API keys can also reach this endpoint, the admin requirement may be unnecessarily restrictive compared to the write-level permission used by the deployment version PATCH route for similar metadata operations.

 

[PlaneInABottle]

this pr became too long, I guess it is better to do it in smaller prs, but I am not sure

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Redundant auth call doubles session lookups for GET

Low Severity

The GET handler calls checkHybridAuth at line 72, and then for all non-internal-precheck requests (session auth, internal JWT with userId), validateWorkflowAccess calls checkHybridAuth again internally at line 147 of middleware.ts. This causes a redundant session/auth lookup on every session-based read of a workflow. The first checkHybridAuth result could be passed into the middleware or the precheck could be restructured to avoid the double call.

Additional Locations (1)

• apps/sim/app/api/workflows/middleware.ts#L146-L155