jason
d53c772dd6
- Node/Express/TypeScript API under /api/v1 with JWT auth (login, refresh, logout, /me) - Prisma schema: vendors, users, roles, products, categories, taxes, transactions - SQLite for local dev; Postgres via docker-compose for production - Full CRUD routes for vendors, users, categories, taxes, products with Zod validation and RBAC - Paginated list endpoints scoped per vendor; refresh token rotation - React/TypeScript admin SPA (Vite): login, protected routing, sidebar layout - Pages: Dashboard, Catalog (tabbed Products/Categories/Taxes), Users, Vendor Settings - Shared UI: Table, Modal, FormField, Btn, PageHeader components - Multi-stage Dockerfile; docker-compose with Postgres healthcheck - Seed script with demo vendor and owner account - INSTRUCTIONS.md, ROADMAP.md, .claude/launch.json for dev server config Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.0 KiB
2.0 KiB
Change Log
All notable changes to this project will be documented in this file.
[4.0.1]
Changed
- Fix advisory GHSA-869p-cjfg-cm3x: createSign and createVerify now require that a non empty secret is provided (via opts.secret, opts.privateKey or opts.key) when using HMAC algorithms.
- Upgrading JWA version to 2.0.1, adressing a compatibility issue for Node >= 25.
[3.2.3]
Changed
- Fix advisory GHSA-869p-cjfg-cm3x: createSign and createVerify now require that a non empty secret is provided (via opts.secret, opts.privateKey or opts.key) when using HMAC algorithms.
- Upgrading JWA version to 1.4.2, adressing a compatibility issue for Node >= 25.
[3.0.0]
Changed
- BREAKING:
jwt.verifynow requires analgorithmparameter, andjws.createVerifyrequires analgorithmoption. The"alg"field signature headers is ignored. This mitigates a critical security flaw in the library which would allow an attacker to generate signatures with arbitrary contents that would be accepted byjwt.verify. See https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ for details.
2.0.0 - 2015-01-30
Changed
-
BREAKING: Default payload encoding changed from
binarytoutf8.utf8is a is a more sensible default thanbinarybecause many payloads, as far as I can tell, will contain user-facing strings that could be in any language. (6b6de48) -
Code reorganization, thanks @fearphage! (
7880050)
Added
- Option in all relevant methods for
encoding. For those few users that might be depending on abinaryencoding of the messages, this is for them. (6b6de48)