These new sessions API calls don’t include the paired session token in an Authorization: Bearer ... header (and fetchJSON currently doesn’t attach one globally). If sessionAuth is enforced for non-localhost requests, fetchSessions/revokeSession (and the rest of the client API calls) will 401 from mobile. Consider plumbing localStorage.getItem('skytwin_session_token') into request headers (either here or centrally in fetchJSON).

qrUrl is built using config.apiPort, but /mobile is a web-SPA route (served by the web app, typically on WEB_PORT, with /api/* proxied separately). As-is, scanning the URL will hit the API server port and likely 404 instead of loading the dashboard. Consider generating the URL using the dashboard/web base (e.g. a new webBaseUrl/webPort config, or an env var) rather than the API port.

GET /api/sessions/:userId lists sessions solely based on the userId path param. With the current auth model, any valid session token would be able to enumerate active sessions for any user by changing the URL. Consider deriving the user identity from the validated session token (e.g. attach session.user_id to req in sessionAuth) and rejecting requests where :userId doesn’t match.

DELETE /api/sessions/:sessionId trusts body.userId to determine ownership. A client with any valid session token could supply another user’s ID (or omit auth entirely if isLocalhost bypass is hit via a proxy) and probe for session IDs. Consider using the authenticated session’s user_id (from middleware) rather than accepting userId from the request body for authorization decisions.

This middleware is async and performs DB calls, but it doesn’t wrap its awaits in a try/catch that calls next(err). In Express 4.x, rejected promises in middleware aren’t automatically forwarded to the error handler, which can lead to unhandled promise rejections and hung requests on DB errors. Consider wrapping the body in try/catch and delegating errors to next.

The error returned for missing/revoked tokens is Invalid session, but the acceptance criteria call for revoked sessions to return the same 401 body as expired sessions ({"error":"Session expired", ...}). Since revoked sessions are filtered out in findByTokenHash, they’ll currently surface as Invalid session. Consider normalizing these responses so revoked tokens produce the same error shape/message as expired tokens.

isLocalhost(req) relies on req.ip / remoteAddress being a loopback address. Because the web app proxies /api/* to the API server from localhost, all browser traffic (including remote mobile traffic) can appear as 127.0.0.1 to the API, unintentionally bypassing auth. Consider enabling trust proxy and basing the bypass on X-Forwarded-For/req.ip from the real client, or moving the bypass decision to the proxy layer so remote clients can’t inherit the localhost bypass.

The UI instructs users to “scan with your phone camera”, but generateQR only renders the URL as plain text (no QR code image/canvas). This doesn’t satisfy the intended QR pairing flow and will be much harder to use on mobile. Consider generating/rendering an actual QR code (e.g., via a lightweight client-side QR library or by returning a QR image/SVG from the API) and only falling back to the raw URL as a copyable alternative.

generateQR explicitly renders a “text-based QR representation (URL)” rather than an actual QR code. If the goal is camera-scannable pairing, this should render a QR code graphic (and ideally provide a one-tap copy button as a fallback).

app.use(sessionAuth) is applied before the SSE router (/api/events). If remote/mobile access is expected, note that EventSource cannot set custom headers (including Authorization), so SSE will 401 unless you explicitly allow the stream endpoint to authenticate via query/cookie or exempt it from header-based auth.

Also, because the web app proxies /api/* to the API server from localhost, the current localhost bypass risks letting remote clients through as “localhost” unless you trust the proxy and use the real client IP for the bypass decision.