Login Integration👑
The generated login is a placeholder — how to swap in your own login and get user ID & role from your own data source.
The generated login page is a placeholder implementation: type a username, pick a role, and you’re in — no password check, no user-table lookup — because generated code doesn’t know what your user table looks like. Its only job is to give the frontend two values: user ID (userid) and role, sent with every request as X-User-Id / X-User-Role headers. The backend uses them for permission (role) and data ownership (user ID) restrictions.
Before going live you must replace it with your own login, and fetch userid and role from your own data source.
Default implementation (placeholder)
| Item | Default behavior |
|---|---|
| Login page | username + role dropdown, no password check |
| Storage | zc_user (user ID), zc_role (role) written to localStorage |
| Transmission | every request automatically carries X-User-Id / X-User-Role headers |
| Backend | reads the two headers: role → permission checks, userid → data-ownership filtering |
The login page is only generated when you need role (permissions) or user ID (data ownership). The placeholder trusts the frontend’s self-declared identity — anyone can pick any role. Dev/demo only; not for production.
Integration points
Login integration = swapping out the “get userid and role” step. The contract is simple: the frontend ultimately hands the current user’s userid and role to the backend — role decides what they can do, userid decides what data they can see. Concretely:
| Location | File | Notes |
|---|---|---|
| Frontend login page (primary hook) | Vue: src/views/LoginView.vue; React: src/views/LoginView.tsx | replace the placeholder doLogin() with your real login flow; after verification, write userid / role |
| Backend identity read (optional) | Java: config/UserContextFilter.java; Go: middleware/auth.go; TS: src/auth/middleware.ts; Python: auth/middleware.py | defaults to reading from headers. To have the backend resolve identity itself (issue a token, you validate it and map role/userid), change this |
Two ways to integrate
Way 1: swap the frontend to your login (simple)
The login page calls your own account system (existing user table / SSO / external OAuth) for verification, then writes the current user’s userid and role into zc_user / zc_role. Request headers and backend logic stay unchanged.
Way 2: backend resolves identity (recommended for production) The frontend stops sending role directly and sends your own token instead; the backend validates the token at the “identity read” point → looks up your user table → maps out role and userid. Identity is verified server-side; the frontend can’t spoof it.
Security notes
- The placeholder trusts the frontend’s self-declared identity — dev/demo only
- After swapping in your own login, put identity verification on the server (Way 2) — don’t let the frontend self-declare role
- Your login system itself: hash passwords with a mature algorithm, keep token secrets in environment variables, use HTTPS in production
FAQ
- I don’t have a user table yet? Use the placeholder login to develop features first; before launch, swap the login page for your own account system — business code (permissions, data ownership) is unaffected.
- Does swapping login affect permissions and data ownership? No — permissions only depend on role, data ownership only on userid. Just hand the backend those two values correctly.
- Can I wire up multiple logins at once? Yes — the login page can offer several entry points, each verified, all landing on the same userid + role.
- Can the placeholder login go live? No. It doesn’t verify identity — any request can self-declare any role. Swap to Way 1 or Way 2 before launch.