fix(admin-auth): reuse exact same QR/session API and component for admin login
Some checks failed
Architecture Governance / architecture (push) Has been cancelled

- Removed invented adminAuthApiUrl endpoint and separate AdminLoginComponent.
  Admin login now uses the exact same Telegram session backend
  (TelegramSessionApiService, {authApiUrl}/users/sessions) and the exact
  same TelegramLoginComponent (mode="customer" | "admin" input) as customer
  login - only the storage (cookie/localStorage/signals) stays separate.
- Extracted the shared HTTP+normalization logic from AuthService into
  TelegramSessionApiService so both AuthService and AdminAuthService call it
  instead of duplicating request/parsing code.
- Documented the resulting backend gap in docs/Project-Editor.md: since the
  session API has no concept of "admin", server-side role enforcement is
  required when admin API calls are made - the frontend only decides where
  to store the session, not whether the user is actually an admin.
This commit is contained in:
sdarbinyan
2026-07-14 10:13:59 +04:00
parent 3877b70fdf
commit 6aec2ebcb2
17 changed files with 316 additions and 789 deletions

View File

@@ -562,16 +562,6 @@ export const en: Translations = {
qrExpired: 'QR code expired. Click to refresh',
qrError: 'Could not create login session. Click to retry',
},
adminAuth: {
loginRequired: 'Admin login required',
loginDescription: 'Log in with your admin account to continue. This is a separate session from the storefront login.',
checking: 'Checking...',
loginWithApp: 'Log in with app',
orScanQr: 'Or scan the QR code',
loginNote: 'You will be redirected back after login',
qrExpired: 'QR code expired. Click to refresh',
qrError: 'Could not create login session. Click to retry',
},
ux: {
items: 'items',
wishlistTitle: 'Wishlist',