arch/mcp-auth: устранить дрейф между enforceBasicLoginGate и AuthController.login (общий pre-token гейт или coupling-тест) #91

New Issue

Ghost · 2026-06-21T02:33:14+03:00

Ghost commented

2026-06-21 02:33:14 +03:00

Найдено в multi-aspect code review (грань: architecture, forward-looking, не блокирует мерж).

Область: apps/server/src/integrations/mcp (enforceBasicLoginGate, mcp.service.ts:230-277) vs apps/server/src/core/auth (AuthController.login)

Наблюдение
enforceBasicLoginGate переповторяет точную pre-token последовательность AuthController.login (validateSsoEnforcement → lazy require EE mfa.service → checkMfaRequirements). Два независимых места обязаны оставаться семантически идентичными.

Значимость
Forward-looking, не баг сегодня (гейты сверены и идентичны по смыслу). Но это самый высоколевереджный риск дрейфа: режим отказа — тихая регрессия security-гейта (повторное открытие SSO/MFA-байпаса).

Опции

Option 1 (medium): единый enforcePreTokenGate(workspace, creds, moduleRef) (или метод AuthService), вызываемый из ОБОИХ login и enforceBasicLoginGate; каждый оставляет своё пост-гейт поведение (cookie vs throw-401). Pros: один источник истины. Cons: рефактор core/auth в большом security-чувствительном дифе.
Option 2 (small): оставить дублирование + coupling-тест, структурно проверяющий, что оба пути вызывают validateSsoEnforcement и проверку MFA (по образцу лока общей константы из этого же PR). Pros: дёшево, ловит выпадение. Cons: дубликат логики остаётся.

Рекомендация
На усмотрение автора. Учитывая большой security-чувствительный диф — Option 2 (coupling-тест) как прагматичный минимум; Option 1 — правильная конечная форма.

Связанные: #70

Найдено в multi-aspect code review (грань: architecture, forward-looking, не блокирует мерж). **Область:** apps/server/src/integrations/mcp (enforceBasicLoginGate, mcp.service.ts:230-277) vs apps/server/src/core/auth (AuthController.login) **Наблюдение** enforceBasicLoginGate переповторяет точную pre-token последовательность AuthController.login (validateSsoEnforcement → lazy require EE mfa.service → checkMfaRequirements). Два независимых места обязаны оставаться семантически идентичными. **Значимость** Forward-looking, не баг сегодня (гейты сверены и идентичны по смыслу). Но это самый высоколевереджный риск дрейфа: режим отказа — тихая регрессия security-гейта (повторное открытие SSO/MFA-байпаса). **Опции** - *Option 1 (medium)*: единый `enforcePreTokenGate(workspace, creds, moduleRef)` (или метод AuthService), вызываемый из ОБОИХ login и enforceBasicLoginGate; каждый оставляет своё пост-гейт поведение (cookie vs throw-401). Pros: один источник истины. Cons: рефактор core/auth в большом security-чувствительном дифе. - *Option 2 (small)*: оставить дублирование + coupling-тест, структурно проверяющий, что оба пути вызывают validateSsoEnforcement и проверку MFA (по образцу лока общей константы из этого же PR). Pros: дёшево, ловит выпадение. Cons: дубликат логики остаётся. **Рекомендация** На усмотрение автора. Учитывая большой security-чувствительный диф — Option 2 (coupling-тест) как прагматичный минимум; Option 1 — правильная конечная форма. **Связанные:** #70

Ghost referenced this issue from a commit

2026-06-21 04:04:47 +03:00

test(mcp): coupling guard between enforceBasicLoginGate and login (#91)

Ghost referenced this issue

2026-06-21 04:19:31 +03:00

fix: review/red-team batch 2 — 30 issues (security, ws, page-templates, html-embed, mcp, tests, docs) #101

Ghost closed this issue

2026-06-21 14:10:33 +03:00

Sign in to join this conversation.