sdarbinyan/marketplaces
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d44565fae948d32e45862c49c00307b317c5ae7f
marketplaces/src/app/components/social-login-button/social-login-button.component.scss

20 lines
403 B
SCSS
Raw Normal View History

feat(identity): provider-agnostic social login, VK ID + Yandex ID (FH-4.1, FH-4.2) The VK-only scaffolding had a shape problem worth fixing before anything was built on it: completeCallback(code, codeVerifier) took the PKCE verifier from the client, which forces the browser to generate and hold it. We are a confidential client - a browser-held verifier buys nothing and adds a place to steal it from. Replaces the four vk-id-* files with a provider-agnostic surface: getAuthorizeUrl(provider, returnTo?) listIdentities() unlink(provider) completeCallback is gone entirely. The backend mints and stores state and code_verifier single-use for 10 minutes, handles the provider's callback itself, issues the session cookie and redirects. VK and Yandex differ only in a path segment, because everything that actually differs between them - PKCE handling, VK's device_id, Yandex's Basic-auth exchange - lives backend-side. vk-id-login becomes social-login-button with a provider input; adding Yandex to the UI is an input value, not new code. Adds yandex_id to ExternalIdentityProvider, plus optional email/phone/displayName since VK frequently returns no email. social-identity-gateway.spec.ts (5 tests) asserts the requests carry no code_verifier and no client_secret, so reintroducing a browser-held verifier fails the build rather than passing review. PHASE-8 §2 rewritten to match: the four endpoints, backend-owned state and verifier, UNIQUE (provider, providerUserId) with conflict routed to controlled resolution rather than a silent rebind, per-tenant OAuth app config under the Track S §4.2 envelope, and both providers' full endpoint sets. Two things recorded there because they are expensive to discover later: VK's callback returns device_id alongside code and the token exchange fails without it, and both providers validate redirect_uri against an exact registered list - which a multi-tenant platform cannot satisfy without a central identity host (FH-0.1, still undecided). 256 tests pass. Build green, boundaries and cycles green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:15:26 +04:00
.social-login-button {
feat: Phase 8 frontend - Customer identity core + standalone VK ID login button core/identity (Customer/ExternalIdentity/ContactChannel models + VkIdGateway/ token/mock) and a standalone VkIdLoginComponent, per Sprint 0.1's "VK ID first" decision and v3.1 §14. Against docs/backend/PHASE-8-IDENTITY-MESSAGING-CONTRACT.md §1-2. Deliberately not wired into TelegramLoginComponent's dialog - that's the live, working QR-login surface for both customer and admin auth (components/telegram-login/), and splicing a second provider into it needs a real VK OAuth app to test against, not a mock bolt-on next to nine other phases. The button is a standalone, ready-to-place component; integrating it into checkout/login flows is follow-up work once VK credentials exist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 23:58:48 +04:00
display: flex;
align-items: center;
justify-content: center;
gap: 8px;
width: 100%;
padding: 10px 16px;
border: 1px solid var(--border-color);
border-radius: var(--radius-md);
background: var(--bg-primary);
color: var(--text-primary);
font-weight: var(--font-weight-bold, 700);
cursor: pointer;
&:disabled {
opacity: 0.6;
cursor: default;
}
}
Reference in New Issue Copy Permalink