fix(dev-server): inject service role token for unauthenticated function calls

[yurynix]

Note

Description

Fixes service-role authorization in the local dev server so asServiceRole works the same way it does in production. Previously the dev server only forwarded the callers own authorization header to functions, so unauthenticated callers (e.g. public-facing subscribe forms) could not perform privileged service-role operations. The dev server now always mints and injects a service-role JWT, and the RLS/FLS engine recognizes the service principal and bypasses access rules accordingly.

Related Issue

None

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Other (please describe):

Changes Made

• Added auth/tokens.ts centralizing JWT minting: createJwtToken, createServiceAuthorizationHeader, SERVICE_ROLE_EMAIL (server@server.com), and isServiceSubject.
• Function proxy (routes/functions.ts) now always injects a freshly-minted Base44-Service-Authorization service token instead of only forwarding the callers authorization header, mirroring production behavior so asServiceRole works for unauthenticated callers.
• resolveCurrentUser (routes/entities/current-user.ts) resolves the service-role JWT subject to a synthetic admin SERVICE_USER with is_service: true.
• RLS/FLS engine (db/rls.ts) short-circuits to allow when user.is_service === true; FLS now treats only undefined rules (not all falsy rules) as "no rule", so explicit false correctly denies normal users while service users bypass it.
• Entity routes (entities-router.ts) let service users bypass an explicit false delete RLS rule, and align read filtering on !== undefined.
• Refactored auth-router.ts to import the shared createJwtToken instead of defining its own, removing the duplicated LOCAL_DEV_SECRET.
• Sorted CLI exports in cli/index.ts (lint fix).

Testing

• I have tested these changes locally
• I have added/updated tests as needed
• All tests pass (npm test)

Checklist

• My code follows the projects style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have updated docs/ (AGENTS.md) if I made architectural changes

Additional Notes

Added tests/cli/dev-rls.spec.ts covering service-user RLS/FLS bypass, and expanded tests/cli/dev.spec.ts with coverage for service-token injection on unauthenticated function calls. The service-role token is local-only and signed with the dev LOCAL_DEV_SECRET.

---

_{🤖 Generated by Claude | 2026-06-04 08:53 UTC | 3d325cb}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.0.52-pr.516.3d325cb

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.0.52-pr.516.3d325cb"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.0.52-pr.516.3d325cb"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.0.52-pr.516.3d325cb
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[artemdemo]

This is not robust enough even for dev.
authorization is user authorization. It means that in case user is logged in locally with newly created user (also locally), then overall permissions will be limited. Which is not expected for server side authorization.

I think approach should be more robust than that.
I think Base44-Service-Authorization should be actual JWT, maybe simple solution will be to create token with email like server@server.com and then in the code check if email is "server" then allow everything. something like that

[artemdemo]

Same goes for Bearer base44-dev-service-token - this token will fail for code that relies on user being presented in JWT:

cli/packages/cli/src/cli/dev/dev-server/routes/entities/current-user.ts

Line 27 in bbc07f1

export async function resolveCurrentUser(