- Each user record has a products array. When a purchase is confirmed
- (planned: via a Polar webhook), a product entry is appended. Apps read the product
- list from the JWT at runtime — no Polar dependency needed outside the webhook handler.
+ Each user record has a products array. Products can be assigned
+ manually via PATCH /api/admin/users/:id/products (superadmin only)
+ or automatically when a purchase is confirmed (planned: Polar webhook).
+ Apps read the product list from the JWT at runtime — no round-trip to
+ rokojori-auth needed.
+ Other rokojori services can resolve an email address to a user ID without
+ a user JWT — useful for migrating member records from email-based to
+ ID-based storage. The caller authenticates with a shared
+ SERVICE_SECRET environment variable, not a user token.
+ Returns { id, email } or 404.
+
@@ -191,6 +208,7 @@ middleware/ requireAuth.ts — JWT verification (cookie or Authorization header) requireAdmin.ts — role guards (requireAdmin, requireSuperAdmin) + requireAccess.ts — flexible role+product access rules (copy into client services) email/ EmailSender.ts — interface SMTPEmailSender.ts @@ -260,6 +278,112 @@
+ Each rokojori service defines an access rule list — a small array
+ that declares who is allowed in. The JWT already carries both roles
+ and products, so no round-trip to rokojori-auth is needed at request time.
+
+ superadmin is implicitly allowed on every service. No service needs
+ to include it in its rule list.
+
type AccessRule = {
+ role: string; // required — user must have this role
+ product?: string; // optional — user must also have this product
+};
+ Multiple rules are OR-combined: access is granted if
+ any rule matches. Within a single rule, role and
+ product are AND-combined.
+
// Grant access to:
+// • any admin (role alone is sufficient)
+// • any user who has the "styles" product
+// • any user who has the "premium" product
+const rules: AccessRule[] = [
+ { role: 'admin' },
+ { role: 'user', product: 'styles' },
+ { role: 'user', product: 'premium' },
+];// source/server/middleware/requireAccess.ts
+
+import { Request, Response, NextFunction } from 'express';
+
+type AccessRule = { role: string; product?: string };
+
+export function requireAccess( rules: AccessRule[] )
+{
+ return ( req: Request, res: Response, next: NextFunction ): void =>
+ {
+ const auth = req.auth;
+ if ( !auth ) { res.status( 401 ).json( { error: 'Not authenticated' } ); return; }
+
+ if ( auth.roles.includes( 'superadmin' ) ) { next(); return; }
+
+ const allowed = rules.some( rule =>
+ auth.roles.includes( rule.role ) &&
+ ( !rule.product || auth.products.includes( rule.product ) )
+ );
+
+ if ( allowed ) { next(); return; }
+ res.status( 403 ).json( { error: 'Forbidden' } );
+ };
+}
+ Use after requireAuth. For browser pages that should redirect
+ rather than return JSON, check req.accepts('html') in the 401/403
+ branches and redirect to
+ account.rokojori.com/login?redirect=<current-url>
+ or back to /.
+
+ Each service defines its own rules inline where the router is mounted.
+ Copy requireAccess.ts into the service's middleware folder —
+ it has no dependencies beyond the shared AuthPayload type
+ from requireAuth.ts.
+
+ Superadmins can set the full product list on any user via the admin route.
+ The body is an array of product ID strings; the server records
+ acquiredAt (now) and source: "manual" for each.
+ The updated list is reflected in the user's next JWT.
+