Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AndrewwCO/Admin-Pana/llms.txt

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

Panahashi Admin delegates identity verification entirely to Firebase Authentication. When you sign in, Firebase validates your credentials and issues a short-lived ID token. That token is then used on every subsequent request to the Panahashi backend API — both to prove your identity and to look up your assigned role. Access to the admin panel is gated behind the ADMIN role, so the application performs a role check immediately after sign-in before letting you reach any protected route.

​
Sign-in flow

1

Enter credentials on the login page

The login page (/) accepts an email address and password. These are passed directly to Firebase Authentication using the signInWithEmailAndPassword method.Firebase validates the credentials against your project’s user store. If they are incorrect, Firebase returns an error and the user stays on the login page.
2

Firebase issues an ID token

On a successful sign-in, Firebase returns an authenticated user object. The application immediately calls user.getIdToken() to retrieve a signed JWT — the Firebase ID token.This token is scoped to your Firebase project, expires after one hour, and is cryptographically signed by Google. The backend uses it to verify that requests come from a legitimately authenticated user.
3

Backend fetches the user profile

With the ID token in hand, the app calls:
GET /api/v1/users/me
Authorization: Bearer <firebase-id-token>
X-User-Name: <email>
The backend validates the token, looks up the matching user record, and returns a profile that includes the user’s role field.
4

Role check and redirect

The app reads the role from the profile response and stores { uid, email, token, role } in React context.
  • If role === "ADMIN" — the user is redirected to /dashboard and can access all admin routes.
  • If role is anything else — the protected route renders an Unauthorized screen. No admin content is accessible.

​
Request headers

Every API call made by the admin panel includes two headers derived from the authenticated user’s context. 
Authorization: Bearer <firebase-id-token>
X-User-Name: <email>
HeaderValuePurpose
AuthorizationBearer <firebase-id-token>Authenticates the request. The backend validates the JWT against Firebase’s public keys.
X-User-NameThe signed-in user’s email addressProvides a human-readable identity for logging and auditing on the backend.
These headers are assembled by the useAuthHeader hook and attached to every Axios request through the shared Axios instance pointed at http://localhost:8080/api/v1.

​
Role enforcement

Any account that signs in with a role other than ADMIN — including CUSTOMER and BAKER — will see an Unauthorized screen immediately after authentication. They cannot navigate to any admin route. There is no partial access; the role check is all-or-nothing.
Role enforcement is applied at the route level via ProtectedRoute. This component does two things:
  1. Checks whether a user is signed in at all. If not, it redirects to / (the login page).
  2. Checks whether user.role === "ADMIN". If not, it renders the Unauthorized message in place of the requested page.
Every page in the admin panel is wrapped in ProtectedRoute, so there is no route that an authenticated non-admin user can reach.

​
Session persistence

Firebase Authentication persists the session in the browser’s local storage by default. When you reload the page, the AuthContext listener (onAuthStateChanged) detects the existing session, silently re-fetches a fresh ID token, and re-validates the user’s role against the backend. You do not need to sign in again on every visit unless your session has expired or you have explicitly signed out.

​
Security considerations

Firebase ID tokens expire after one hour. The Firebase SDK handles token refresh automatically in the background. If the refresh fails (for example, the account is disabled), the auth state listener fires with null, and the user is redirected to the login page.
Changing a user’s role in the Panahashi backend takes effect on their next API call, since the role is fetched from GET /api/v1/users/me on each session start. To revoke access immediately, disable the account in the Firebase console — this invalidates the ID token and forces a sign-out.
The Firebase configuration values (VITE_FIREBASE_API_KEY, etc.) are embedded in the browser bundle at build time. These values identify your Firebase project but do not grant backend access on their own — the backend validates the signed ID token, not the API key. Keep your Firebase Security Rules tight to prevent unauthorized use of client-side keys.

Build docs developers (and LLMs) love

Get started for freeTalk to us