active-svelte/demos/dating/docs/auth-y-fotos.md

Auth y fotos de perfil

Objetivo

Definir de forma implementable las paginas de login, registro, recuperacion, MFA simulado y gestion de fotos de perfil. Estos flujos son obligatorios porque prueban auth, session, sium, http, storage, cache, perm, logger, bus, orca, frontend, adom, lang, format y PocketBase como backend local.

Rutas de autenticacion

/dating/login

Pantalla dedicada para iniciar sesion.

Campos:

• email;
• password;
• recordarme en este dispositivo;
• idioma;
• tema.

Estados:

• idle;
• submitting;
• invalid credentials;
• account limited;
• session restored;
• mfa required;
• network error;
• offline.

Integraciones:

• sium: schema de login.
• auth: login.
• session: guardar sesion activa.
• http: request al endpoint.
• storage: preferencia local de dispositivo si aplica.
• logger: trace sin password.
• bus: evento dating.auth.login.
• orca: flujo login -> session -> redirect.

/dating/register

Pantalla dedicada para crear cuenta.

Campos:

• email;
• password;
• confirm password;
• nombre visible inicial;
• confirmacion de edad adulta;
• aceptacion de reglas de demo/privacidad local.

Estados:

• idle;
• submitting;
• email already used;
• weak password;
• adult confirmation missing;
• created;
• redirect to onboarding.

Integraciones:

• sium: schema de registro y confirmacion de password.
• auth: register.
• session: iniciar sesion tras registro si procede.
• perm: rol inicial user.
• logger: evento de seguridad redacted.
• bus: dating.auth.registered.
• orca: register -> session -> onboarding draft.

/dating/reset

Recuperacion simulada. La UI no debe revelar si el email existe.

Campos:

• email.

Estados:

• idle;
• submitting;
• sent;
• network error.

/dating/mfa

MFA simulado para probar flujo, aunque la primera version local no tenga MFA real activado.

Campos:

• codigo de 6/8 digitos;
• recuperar acceso;
• confiar en dispositivo si se habilita.

Estados:

• pending;
• invalid code;
• expired code;
• verified;
• locked.

Componentes de auth

Componentes candidatos a uix:

• AuthLayout
• LoginForm
• RegisterForm
• ResetPasswordForm
• MfaChallenge
• SessionRestoreGate
• AuthError

Componentes especificos de dating:

• DatingAuthHeader
• DatingPrivacyNotice

Fotos de perfil

Modelo inicial

La demo usa el campo photos de dating_profiles en PocketBase:

• tipo file;
• maximo 6 fotos;
• formatos: JPEG, PNG, WebP;
• tamano maximo: 5 MB por foto;
• thumbnails: 120x120 y 400x600.

Para v2 avanzada se puede extraer una coleccion dating_profile_photos si se necesita moderacion por foto, orden individual persistente, captions o estados por archivo. Para la demo inicial, el campo file multiple es suficiente.

/dating/profile/photos

Pantalla dedicada para gestionar fotos.

Funciones:

• subir fotos por selector;
• drag and drop;
• preview antes de guardar;
• ordenar fotos;
• marcar foto principal;
• eliminar foto;
• reemplazar foto;
• mostrar progreso de subida;
• mostrar errores por archivo;
• guardar cambios;
• cancelar y recuperar estado anterior.

Estados:

• empty;
• local preview;
• uploading;
• uploaded;
• upload failed;
• too many files;
• invalid type;
• file too large;
• reorder pending;
• deleting;
• saved.

Validaciones

Cliente:

• maximo 6 fotos;
• tipos permitidos;
• tamano maximo;
• no permitir publicar perfil visible sin al menos una foto si esa regla esta activa;
• alt text o descripcion opcional para accesibilidad futura.

Servidor:

• repetir limites de tipo/tamano;
• comprobar que el perfil pertenece al usuario;
• moderador/admin puede ocultar o borrar fotos si se implementa;
• usuario limitado puede tener subida bloqueada segun perm.

Integraciones

• sium: schema de metadata de fotos y reglas de perfil.
• http: upload multipart al endpoint de perfil.
• cache: invalidar profile.me, discover.feed y perfiles vistos.
• storage: guardar previews/draft solo como metadata local, no blobs grandes salvo decision explicita.
• perm: profile:photo:add, profile:photo:delete, profile:photo:reorder.
• logger: trazas sin incluir contenido binario.
• bus: eventos dating.profile.photo.added, dating.profile.photo.removed, dating.profile.photo.reordered.
• orca: coordinar upload -> cache invalidation -> profile refresh -> discover refresh.
• adom: drag/drop, focus restore, keyboard reordering.
• frontend: layout responsive del gestor.

Endpoints requeridos

Estos endpoints los sirve el servidor independiente servers/dating, no SvelteKit:

• POST /api/auth/register
• POST /api/auth/login
• POST /api/auth/logout
• POST /api/auth/reset
• POST /api/auth/mfa/verify
• GET /api/session
• POST /api/profile/photos
• DELETE /api/profile/photos/:filename
• PATCH /api/profile/photos/order
• PATCH /api/profile/photos/main

Reglas de permisos

Accion	Usuario	Limitado	Moderador	Admin
auth:login	si	si	si	si
auth:logout	si	si	si	si
profile:photo:add	si	no	si	si
profile:photo:delete:self	si	parcial	si	si
profile:photo:moderate	no	no	si	si
profile:photo:reorder	si	no	si	si

Tests minimos

• login correcto redirige a discover u onboarding.
• login invalido no crea sesion.
• registro crea usuario dating_users y redirige a onboarding.
• recuperacion no revela si el email existe.
• MFA invalido muestra error y conserva challenge.
• upload de foto valida actualiza dating_profiles.photos.
• upload de tipo invalido falla antes de enviar.
• upload superior a 5 MB falla.
• usuario limitado no puede subir foto.
• eliminar foto invalida cache de perfil/discover.
• reordenar fotos conserva la foto principal.
• devtools muestra eventos/logs sin exponer password ni binarios.