REST API: every Bearer API-key request returns HTTP 500 "attempt to write a readonly database" (TokenValidationService::syncLastUsedToDatabase)

[okacyzzz-oss]

Summary
Authentication with an API key (Authorization: Bearer ) always fails with HTTP 500 on an LXC installation. TokenValidationService tries to save the key's last-used time to the main database from the php-fpm process, which runs as www and cannot write /cf/conf/mikopbx.db. The exception is not caught, so every request with an API key fails, including requests the key should allow.

Evidence
Server: MikoPBX 2026.3.40 (Asterisk 22.8.2) in an LXC container, PHP 8.4
/cf/conf/mikopbx.db: owner root:root, mode 0644 (as created by the installer)
php-fpm pool user: www
API key: full_permissions false, allowed_paths {"/api/v3/employees": "write"}

Request Allowed by the key Expected Actual
GET /pbxcore/api/v3/employees?limit=5 yes 200 500
GET /pbxcore/api/v3/employees/121 yes 200 500
GET /pbxcore/api/v3/extensions no 403 500
GET /pbxcore/api/v3/api-keys no 403 500

System log (on every request):
PDOException: SQLSTATE[HY000]: General error: 8 attempt to write a readonly database in src/PBXCoreREST/Services/TokenValidationService.php on line 204
Phalcon\Mvc\Model->save() TokenValidationService.php:204
TokenValidationService->syncLastUsedToDatabase() TokenValidationService.php:187
TokenValidationService->updateLastUsedBuffer() TokenValidationService.php:115
TokenValidationService->validatePermissions() TokenValidationService.php:85
TokenValidationService->validate() Middleware/AuthenticationMiddleware.php:188
AuthenticationMiddleware->authenticateWithBearerToken() Middleware/AuthenticationMiddleware.php:98

Expected Behavior
A valid API key is accepted (200), and a path that is not in allowed_paths is rejected (403). The last-used time is informational and should never break authentication.

Potential Root Cause
validatePermissions() calls updateLastUsedBuffer(), which calls syncLastUsedToDatabase() when LAST_USED_SYNC_INTERVAL (60 s) has passed since the last sync. syncLastUsedToDatabase() runs ApiKeys::findFirst($keyId)->save() directly inside php-fpm. The main database is read-only for www, so save() throws, and nothing catches the exception.

The ":sync" cache key is written only after syncLastUsedToDatabase() returns. Because the save throws, the key is never written, so the sync is attempted (and fails) on every request and the 60-second throttle never takes effect. API-key authentication is therefore completely unusable on this installation.

The same code exists on the develop branch.

Requests from 127.0.0.1 without a key are not affected: they do not reach this code path, and data writes are performed by the backend worker running as root.

Possible fixes:
Wrap the last-used update in try/catch and log the error instead of failing authentication, and write the ":sync" key before attempting the save
Hand the last-used update to a backend worker (as other writes are handled) instead of saving from php-fpm

Reproduction
Install MikoPBX 2026.3.40 in an LXC container (database owned by root:root 0644, php-fpm running as www)
Create an API key: description "test", full_permissions false, allowed_paths {"/api/v3/employees": "write"}
From another host: curl -k -H "Authorization: Bearer " "https:///pbxcore/api/v3/employees?limit=5"
The response is HTTP 500, and the system log shows the PDOException above

Files to Investigate
src/PBXCoreREST/Services/TokenValidationService.php — updateLastUsedBuffer(), syncLastUsedToDatabase()
src/PBXCoreREST/Middleware/AuthenticationMiddleware.php — authenticateWithBearerToken()

[miko-service-bot]

Triage summary

Classification: Core bug — confirmed via code analysis. No live reproduction attempted; not needed, the code path is unambiguous.

Environment reported

• MikoPBX 2026.3.40 (Asterisk 22.8.2), PHP 8.4, LXC container
• /cf/conf/mikopbx.db owner root:root, mode 0644, php-fpm pool user www
• API key with full_permissions=false, allowed_paths={"/api/v3/employees":"write"}

Root cause — verified by code reading

The reporter's diagnosis matches develop exactly. The failing path is:

AuthenticationMiddleware::authenticateWithBearerToken()
→ TokenValidationService::validate()
→ validatePermissions()
→ updateLastUsedBuffer()
→ syncLastUsedToDatabase() → ApiKeys::findFirst()->save()

In src/PBXCoreREST/Services/TokenValidationService.php (develop, SHA 3a419b9424ee58fc731c1cf080743ff11395e125):

private function updateLastUsedBuffer(int $keyId): void
{
    // ...
    if ($now - $lastSync > self::LAST_USED_SYNC_INTERVAL) {
        $this->syncLastUsedToDatabase($keyId, $now);          // throws under www
        $this->cache->set($bufferKey . ':sync', $now, ...);   // never reached
    }
}

Two independent design problems, both real:

1. Uncaught write from php-fpm. save() runs inside the request process (www), which is not the writer that owns /cf/conf/mikopbx.db. Any write failure (permission, lock, transient) surfaces as an unhandled PDOException → HTTP 500. This is a design bug regardless of file permissions on a specific installer image; other writes in the codebase are dispatched to root-privileged backend workers precisely to avoid this.
2. Throttle never engages when the write throws. The :sync cache key is written after syncLastUsedToDatabase() returns. When the save throws, $lastSync stays 0, so every subsequent request re-enters the sync branch and re-fails. The 60-second throttle is bypassed. This turns a "silent last-used bookkeeping" feature into a hard 100% authentication failure.

Status in develop

• File on develop (SHA 3a419b9424ee58fc731c1cf080743ff11395e125) is byte-identical to master (SHA b184a7199434fd16b8e81f5a02d6b346db2d6eeb) in the relevant methods. No fix has landed.
• Most recent commit touching this file is c82e0db6 (Oct 24 2025, "remove verbose debug logging"), which only trimmed log messages — did not alter updateLastUsedBuffer() / syncLastUsedToDatabase().
• The whole granular-permissions/Bearer-token stack was introduced in b3fae73b (Oct 20 2025); the write-from-www hazard was in the initial version.

Label: likely-fixed-in-develop — no (fix is not present in develop).

Test coverage

tests/Unit/PBXCoreREST/Services/ contains only ApiKeyPermissionCheckerPathAscendTest.php. There is no unit or REST-API integration test that exercises TokenValidationService::validate() under a non-writable DB (or at all). Marked no-tests for this area — a regression test that mocks a failing save() and asserts a 200/403 response (not 500) would be worthwhile alongside the fix.

Reproducibility & scope

• code-analysis-only — the code path is deterministic given the reported install shape (php-fpm as www, DB owned root:root 0644). Anyone on the same install shape will hit this on 100% of Bearer API-key requests.
• Requests from 127.0.0.1 and cookie-authenticated web UI users do not enter this code path (AuthenticationMiddleware::call() checks localhost and public endpoints before Bearer). So the web UI keeps working — this is why the bug can escape internal testing.
• Only one report so far (REST API: every Bearer API-key request returns HTTP 500 "attempt to write a readonly database" (TokenValidationService::syncLastUsedToDatabase) #1120). REST-API Bearer keys were introduced very recently, so a low report count is expected; anyone actually using API keys on LXC/Docker will hit this.

Severity: high

• Blocks 100% of Bearer API-key traffic on affected installs.
• Web UI and localhost integrations unaffected.
• Not critical because it doesn't take down the PBX itself; call handling and admin access are unaffected.

Workaround (for other users landing here)

Until a fix ships, one of:

• chown www:www /cf/conf/mikopbx.db (or chmod g+w and put www in the owner group) — makes the DB writable from php-fpm. Warning: survives until the next installer/upgrade touches the file.
• Use cookie-based session auth via the web UI, or run REST requests from 127.0.0.1 without an API key (Bearer path is skipped entirely).

Neither is a proper fix; both are here so users aren't stuck.

Suggested fixes (for maintainer review)

Both fixes the reporter proposed are sound; ideally do both:

1. Guard the write. Wrap syncLastUsedToDatabase() in try/catch (\Throwable), log at LOG_WARNING, and — critically — set the :sync cache key before attempting the DB write, not after. That way a failing save still engages the 60-second throttle instead of retrying on every request.
2. Move the write off the request path. Hand last_used_at updates to a backend worker (same pattern as other writes to mikopbx.db), so php-fpm never touches the main DB. This also removes a small latency tax from every authenticated API call.

last_used_at is informational (UI display, key-hygiene reporting). It must not be able to fail authentication.

Related

• No duplicate issues found.
• No open PR addressing this. Search TokenValidationService, last_used_at, syncLastUsedToDatabase returned 0 PRs.

Recommendation: ready-for-maintainer-review

Suggested labels: bug, core, rest-api, high, code-analysis-only, no-tests

Note on PRs: per this repo's triage rules, no PR is opened without explicit maintainer request. Happy to prepare one along the lines above if @mikopbx maintainers ask.

---

Generated by Claude Code