Skip to content

Authentication

In production mode (the in-process copy)

The dashboard router has no auth middleware of its own in production mode. The routes/index.js isLocal === false branch does not call router.use(auth).

This is because the production deployment mounts the dashboard router as a child of the main someli-api Express app at /auth (per someli-api/CLAUDE.md § Route Modules). The path-prefix /auth is significant — someli-api/middlewares/auth.js is registered before this prefix and gates every request, extracting userId, role, and accountId from an encrypted token and writing them onto the response object (res.userId, res.accountId).

By the time a request reaches a handler in routes/index.js, the upstream middleware has already either: 1. Authenticated the user and set res.userId + res.accountId, or 2. Rejected the request with a 401 before the handler runs.

So the handlers can safely do let { userId, accountId } = res; without any auth check.

For the auth implementation, see ../someli-api/authentication.md.

In local-dev mode (the standalone)

routes/index.js:25 calls router.use(auth) where auth = require("../mock/middlewares/auth"). The mock middleware does not validate anything — it sets fake userId and accountId values on res and calls next() unconditionally.

This makes the standalone repo trivially insecure if anyone ever accidentally deploys it. Mitigation: ensure it is never reachable over a public network in NODE_ENV=development mode.

Express session middleware

server.js:8-12 configures express-session:

app.use(expressSession({
  secret: process.env.SESSION_SECRET || "change-me",
  resave: false,
  saveUninitialized: true
}))

The handlers in routes/index.js do not read or write req.session. The session middleware is unused. The hardcoded fallback secret "change-me" is a security finding (see security.md) but the practical impact is low because nothing depends on the session.

Implication for the standalone

If the team decides to extract this repo into a real standalone service (Path B in relationship-to-someli-api.md), authentication is the first non-trivial problem to solve:

  • The current "auth happens upstream" model only works because the dashboard is mounted into a larger app whose middleware chain handles it.
  • A standalone service needs its own token-validation middleware. The cleanest option is to share the same tokenGenerator.js (already an identical file in someli-api/helper/ and Someli-admin-api/helper/) and re-implement the userId/role/accountId extraction here, OR to validate the JWT and look up the account on each request.
  • The hand-rolled fake-res injection (res.userId = ...) of the existing in-process code is a code smell — res is the response object, not a request-context object. A real standalone service should put auth data on req.user instead.