@meldkit/dev-auth

A token endpoint for development. It stands in for your backend.

Minting a MeldKit access token requires your project's secret key, and that key must never reach the browser. This reads it server-side and sends back only the short-lived token — which is exactly what the SDK's auth option fetches.

npm install --save-dev @meldkit/dev-auth

Two shapes, depending on what your dev server gives you to hook into.

Middleware, for anything Connect-style — this is what @meldkit/vite wraps:

import { authHandler } from '@meldkit/dev-auth';
server.middlewares.use(authHandler());

A server of its own, for dev servers with no middleware — the Angular CLI, say, where you point proxyConfig at it:

// dev-server.mjs
import { serveAuth } from '@meldkit/dev-auth';
serveAuth({ port: 5174 });

// proxy.conf.json
{ "/api/meldkit-auth": { "target": "http://localhost:5174" } }

It reads MELDKIT_SECRET_KEY from the environment — no VITE_/NG_ prefix, which is the point. Run it with node --env-file-if-exists=.env dev-server.mjs to pick up a local .env.

What it does not decide

Two things, and they are the two you have to replace before this goes anywhere near production:

• userId — who is asking. The default issues a per-browser cookie, which is right for a demo with no accounts and wrong for anything with a login. Never take it from the request body: a client that can name its own user id can name someone else's. MeldKit meters usage by distinct user id per month, so an id that changes per tab inflates your bill.
• authorize — may this user open this room? Defaults to yes. MeldKit cannot answer this; only you know who your users are.

In production this is a route in your own app, and it is about twenty lines. See the authentication docs.

Not for production

Nothing here is dangerous by itself — it is the same POST /v1/tokens call your backend makes — but it ships with both decisions above defaulted to the permissive answer. Keep it a devDependency.