Skip to content

Authentication

Login flow (designer FE)

Someli-Designer (Nuxt + @nuxtjs/auth) POSTs /webauthenticate with { email, password }. The handler in routes/routes.js (line ~171):

router.post("/webauthenticate", (req, res, next) => {
  ...
});

Verifies credentials against tMember (with bcryptjs), returns a token. The token format is not the encrypted-token used by Someli-admin-api; this repo doesn't have a tokenGenerator.js or crypto-js dep. Instead, it returns a plain JSON envelope with user info; the FE attaches it to subsequent requests as a header.

Verify the exact token format by reading the webauthenticate handler body.

/me endpoint

router.get("/me", (req, res, next) => {
  ...
});

Returns the current user. The FE calls this on app load to bootstrap the session.

No middlewares/

Unlike someli-api and Someli-admin-api, this repo has no middlewares/ directory. There is no auth.js middleware, no validation.js. Auth is done inline in each handler (or not at all).

What this means

  • Every route in routes/routes.js is potentially unauthenticated unless the handler explicitly checks for a token / user
  • There is no per-route declarative auth — protection is by convention
  • Audit risk: a new endpoint added without a token check is publicly callable

How protection actually works

A spot-check of the route handlers suggests the convention is to read the apptype and a custom auth header off req, then validate against tMember. Without a standard middleware, every handler reimplements this. Drift / forgetting is the failure mode.

Recommendation

  1. Add a middlewares/auth.js that validates the FE's token, sets req.user (or res.user per the platform's odd convention), and next()s.
  2. Apply it as router.use(auth) at the top of init() for all protected routes.
  3. Carve out unauthenticated endpoints (login, public health check) with an explicit allowlist.

This is a 1-2 day refactor with major security upside.

CORS

server.js: 

app.use(cors());
app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('"Access-Control-Allow-Credentials" : true');
    next();
});

  • cors() with no options → wildcard origin
  • Plus a manual wildcard
  • The second header "Access-Control-Allow-Credentials" : true is malformed — the entire string is the header name. Browsers ignore. Probably intended Access-Control-Allow-Credentials: true.

The wildcard origin is permissive. For an internal tool, this is moderate risk — the designer FE host should be the only allowed origin.

Logout

Not documented in this audit. The FE (Someli-Designer) uses @nuxtjs/auth's logout: false strategy — meaning logout is purely client-side. The BE has no logout endpoint.

Cross-cutting note

The four backends use four different auth patterns:

Repo Auth pattern
someli-api encrypted-token header via middlewares/auth.js; also passport for OAuth
Someli-admin-api encrypted-token header (same crypto as someli-api) + Bearer JWT (methods.ensureToken)
designer-api custom token, inline per-handler (no shared middleware)
someli-dashboard-be "auth happens upstream" assumption (no auth in this repo)

A platform-wide auth model would simplify everything. See the platform-level recommendations in ../PLATFORM-OVERVIEW.md.