Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_WEB/llms.txt

Use this file to discover all available pages before exploring further.

Dragon Guard WMS Web authenticates every operator through a JWT-based login flow enforced by Angular route guards. Tokens are scoped to a single browser session, and tenant users must belong to exactly one operational company before the dashboard becomes accessible. Supreme administrators bypass company-scoping and gain access to global routes directly.

Login Flow

1

Enter Credentials

The operator navigates to the login screen and provides an email address and password. When Remember me is checked, the email address is persisted in localStorage for convenience on the next visit — the password and token are never stored there.
2

Call AuthService.login()

The Angular AuthService posts the credentials to the backend (Wms.Api). The backend is the authoritative validator — no client-side credential logic is applied.
3

Backend Validates and Returns JWT

On success the API returns a signed JWT token. The token carries role and company claims that the frontend reads to enforce the multi-company rule described below.
4

AuthService.saveSession() Validates Company Context

Before writing anything to sessionStorage, saveSession() inspects the tenant context:
  • SUPERADMIN_SUPREMO — no active company is required; supreme routes are unlocked.
  • Tenant user with exactly one operational company — the company is stored and the user proceeds.
  • Tenant user with zero companies — access is denied; the login screen shows a business message.
  • Tenant user with more than one company — access is also denied; auto-pick is not allowed.
5

Temporary Password Check

If the response includes mustChangePassword: true, the user is immediately redirected to /change-password. Dashboard access is blocked until the password is updated.
6

Dashboard Access Granted

Tenant users who pass the company-context check are forwarded to the dashboard with a fully populated session. Supreme admins reach global routes without an active_company_id.

Temporary Password Policy

New accounts are provisioned with the temporary password 123456789. The system enforces a change on first login. The new password must satisfy all of the following rules:
RuleRequirement
Minimum length8 characters
Uppercase letterAt least one (A–Z)
Lowercase letterAt least one (a–z)
NumberAt least one (0–9)
Special characterAt least one (e.g. !@#$%^&*)

Session Storage Keys

All active-session data is written exclusively to sessionStorage. The values are cleared automatically when the browser tab or window is closed.
KeyTypeDescription
tokenstringSigned JWT used in every API request header
user_emailstringAuthenticated operator’s email address
user_namestringDisplay name of the authenticated operator
active_company_idstringID of the single operational company for tenant users
active_rolestringRole granted to the current session
is_supreme_adminbooleantrue only for SUPERADMIN_SUPREMO accounts
must_change_passwordbooleantrue until the operator completes a password change
available_company_countnumberNumber of operational companies linked to the account
Never store the JWT token in localStorage. Tokens written to localStorage survive beyond the browser session and are accessible to any JavaScript running on the same origin, including third-party scripts. Only the operator’s email address may be saved to localStorage, and only when the Remember me checkbox is explicitly checked by the user.

Multi-Company Access Rules

Dragon Guard WMS supports multiple tenants and multiple companies per tenant. The rules below are enforced at saveSession() time — not at the route level — so invalid contexts never produce a partial session.

Supreme Admin

SUPERADMIN_SUPREMO accounts do not require an active_company_id. They access global administration routes directly and are never blocked by company-count checks.

Tenant User

Must be linked to exactly one operational company. Zero companies or more than one company both result in a denied login with a descriptive business message shown on the login screen.
There is no auto-selection mechanism when a tenant user belongs to more than one company. The administrator must correct the company assignment in the backend before the user can log in.

JWT Authorization Header

Every HTTP request to Wms.Api must include the token retrieved from sessionStorage:
Authorization: Bearer {token}
Angular’s HTTP interceptor attaches this header automatically. If the token is absent or expired, the interceptor redirects the operator to the login screen.

Route Guard Behaviors

Angular route guards protect every authenticated route. The table below summarises each enforcement scenario.
ConditionGuard Action
Token is missing from sessionStorageRedirect to /login
Token is expiredClear session, redirect to /login
must_change_password is trueForce navigation to /change-password; all other routes blocked
Tenant user has invalid company contextRedirect to /login with business error message
Supreme admin accessing global routeAllowed; company-context check is skipped
Tenant user accessing dashboardAllowed only when active_company_id is present and valid
During development, inspect sessionStorage in the browser DevTools Application tab to verify that all expected keys are populated after login. If active_company_id is missing for a tenant user, the guard will silently redirect back to the login screen.

Security Rules Summary

  • Tokens and passwords must never appear in application logs or console output.
  • Tokens must only be stored in sessionStorage — never in localStorage, cookies, or component state.
  • The backend (Wms.Api) is the sole authority for credential validation and role assignment.
  • Client-side role checks are used for UX only; the backend enforces all authorization on every API call.

Build docs developers (and LLMs) love