# VRM Backend — Vulnerability Risk Manager User Registration API

## Identificación del Proyecto

| Campo              | Valor                                                      |
|--------------------|------------------------------------------------------------|
| **ID**             | PROJ-W04                                                   |
| **Nombre**         | VRM Backend — User Registration API                        |
| **Tipo**           | API Backend — VRM (Vulnerability Risk Manager)             |
| **Worker CF**      | `vrm-backend`                                              |
| **Dominio**        | Por configurar (ej: api.vulnerafix.com/vrm/*)              |
| **Responsable**    | Daniel (dev) · Cloudflare (infra)                          |
| **Fecha registro** | 2026-03-10                                                 |
| **Estado**         | ✅ PRODUCCIÓN — 100% OPERATIVO                             |
| **Prioridad**      | ALTA                                                       |

---

## Descripción

API backend de soporte para la herramienta VRM (Vulnerability Risk Manager) de vulnerafix.com. Gestiona el registro y autenticación de usuarios. El código actual está roto por uso de una API incompatible con Cloudflare Workers y requiere reescritura completa usando D1 como base de datos.

### Propuesta de valor
- Backend de soporte directo para vulnerafix.com
- Autenticación segura con hashing PBKDF2
- Integración con `vulnerafix_db` (D1) — base de datos ya existente y poblada
- Infraestructura serverless en Cloudflare Workers

---

## Arquitectura objetivo (post-reescritura)

```
Cliente (vulnerafix.com / VRM Tool)
    → POST /register | POST /login
        → CF Worker (vrm-backend)
            → D1: vulnerafix_db (env.DB)
                → Tabla: users (registro / validación)
                → Tabla: sessions (gestión de sesiones)
            ← 200 OK + token | 400 Bad Request | 401 Unauthorized
```

### Stack Tecnológico

| Capa           | Tecnología            | Estado actual          | Estado objetivo       |
|----------------|-----------------------|------------------------|-----------------------|
| Runtime        | Cloudflare Workers    | Desplegado (roto)      | Reescribir + redeploy |
| Base de datos  | Cloudflare D1 (SQL)   | Sin binding            | D1 `vulnerafix_db`    |
| Auth           | PBKDF2 + Sessions     | No implementado        | Implementar           |
| Bindings CF    | D1 `DB`               | NINGUNO                | Configurar            |

---

## Endpoints

### Estado actual (diseñado, código roto)

| Endpoint    | Método | Descripción                               | Estado       |
|-------------|--------|-------------------------------------------|--------------|
| `/health`   | GET    | Health check del Worker                   | Diseñado     |
| `/register` | POST   | Registro de usuarios (email + password)   | ROTO         |

### Endpoints adicionales necesarios (reescritura)

| Endpoint  | Método | Descripción                          | Estado    |
|-----------|--------|--------------------------------------|-----------|
| `/login`  | POST   | Autenticación de usuarios            | Pendiente |

---

## Bug critico — causa del estado roto

El código actual usa la siguiente llamada:

```js
context.services.get("mongodb-atlas")
```

Esta es la API de **MongoDB App Services (Realm)** — un entorno completamente distinto a Cloudflare Workers. Esta llamada **nunca ha funcionado** en un Worker de CF y no existe forma de hacerla funcionar sin reescribir el código.

**Consecuencia:** El Worker se despliega pero falla en runtime en cualquier llamada que intente acceder a la base de datos.

---

## Bindings de Cloudflare (estado actual)

| Binding     | Tipo | Nombre en código | Recurso CF       | UUID                                   | Estado |
|-------------|------|------------------|------------------|----------------------------------------|--------|
| D1 Database | D1   | `DB`             | `vulnerafix_db`  | `0a24b289-71e3-471e-bdcc-c6a1b524c1ca` | FALTA  |

**PROBLEMA CRITICO:** El Worker `vrm-backend` no tiene NINGUN binding configurado. El binding D1 debe agregarse en el redeploy.

---

## Base de datos D1 disponible

**Database:** `vulnerafix_db` — UUID: `0a24b289-71e3-471e-bdcc-c6a1b524c1ca`

| Tabla         | Descripción                             | Uso en VRM Backend           |
|---------------|-----------------------------------------|------------------------------|
| `users`       | Usuarios registrados                    | POST /register, POST /login  |
| `sessions`    | Sesiones activas                        | POST /login (token/session)  |
| `permissions` | Permisos por usuario                    | Referencia futura            |
| `links`       | URLs cortas asociadas a usuarios        | Referencia futura            |
| `clicks`      | Clicks en links de usuarios             | Referencia futura            |

---

## Plan de reescritura (Daniel)

### Cambios obligatorios

1. **Eliminar** toda referencia a `context.services.get("mongodb-atlas")`
2. **Reemplazar** acceso a DB con `env.DB.prepare(...).run()` / `.first()` / `.all()`
3. **Implementar** hashing de password con **PBKDF2** antes de guardar — nunca texto plano
4. **Agregar** endpoint `POST /login` para completar el flujo de autenticación

### Pseudocódigo objetivo — `/register`

```js
// POST /register
const { email, password } = await request.json()
const hashed = await hashPBKDF2(password)  // PBKDF2, nunca texto plano
await env.DB.prepare(
  "INSERT INTO users (email, password_hash) VALUES (?, ?)"
).bind(email, hashed).run()
return new Response(JSON.stringify({ success: true }), { status: 201 })
```

### Pseudocódigo objetivo — `/login`

```js
// POST /login
const { email, password } = await request.json()
const user = await env.DB.prepare(
  "SELECT * FROM users WHERE email = ?"
).bind(email).first()
const valid = await verifyPBKDF2(password, user.password_hash)
if (!valid) return new Response("Unauthorized", { status: 401 })
// Crear session token y guardar en sessions
return new Response(JSON.stringify({ token }), { status: 200 })
```

---

## Estado por fases (Closer)

### Fase 1 — Diagnóstico (COMPLETADA)
- [x] Identificar bug crítico: `context.services.get("mongodb-atlas")` inválido en CF Workers
- [x] Identificar D1 disponible: `vulnerafix_db` con tablas users, sessions, permissions

### Fase 2 — Reescritura (PENDIENTE)
- [ ] **[Daniel]** Reescribir `/register` usando `env.DB` (D1) + PBKDF2
- [ ] **[Daniel]** Implementar `/login` con validación y generación de session token
- [ ] **[Daniel]** Mantener `/health` funcional
- [ ] **[Daniel]** Redeploy del Worker con wrangler

### Fase 3 — Bindings y Configuración
- [ ] **[Cloudflare]** Agregar binding D1 `DB` → `vulnerafix_db` (`0a24b289...`) al momento del redeploy
- [ ] **[Cloudflare]** Configurar route (ej: `api.vulnerafix.com/vrm/*`)

### Fase 4 — Integración y decisión arquitectónica
- [ ] **[Daniel + Cloudflare]** Evaluar: fusionar con Worker `lucky-bush-a6e2` (ya tiene auth completo) o mantener `vrm-backend` como microservicio independiente
- [ ] Prueba end-to-end desde vulnerafix.com → `/register` → `/login`
- [ ] Integración con VRM Tool en producción

---

## Condición real / Observaciones

| Área              | Condición                                                            |
|-------------------|----------------------------------------------------------------------|
| Código Worker     | Desplegado pero roto — API MongoDB incompatible con CF Workers      |
| Bindings CF       | NINGUNO configurado                                                  |
| Base de datos     | `vulnerafix_db` existe y tiene schema completo — listo para usar    |
| Endpoint /health  | Diseñado, probablemente funcional si no accede a DB                 |
| Endpoint /register| ROTO por `context.services.get("mongodb-atlas")`                    |
| Endpoint /login   | No implementado aún                                                  |
| Seguridad         | Password nunca debe guardarse en texto plano — usar PBKDF2          |
| Alternativa       | Worker `lucky-bush-a6e2` tiene auth completo — evaluar fusión       |

---

## Agentes responsables

| Agente     | Responsabilidad sobre este proyecto                                 |
|------------|---------------------------------------------------------------------|
| Daniel     | Reescritura del código, implementación D1, PBKDF2, redeploy        |
| Cloudflare | Binding D1 al redeploy, configuración de route                     |

---

## Acciones pendientes (próximos pasos)

- [ ] **[Daniel]** Reescribir `/register` eliminando `context.services.get("mongodb-atlas")` y usando `env.DB`
- [ ] **[Daniel]** Implementar `/login` con PBKDF2 + session token
- [ ] **[Daniel]** Redeploy con wrangler incluyendo binding D1 `DB` → `vulnerafix_db`
- [ ] **[Cloudflare]** CF Dashboard → Workers → `vrm-backend` → Settings → Bindings → agregar `DB` (D1: `0a24b289...`)
- [ ] **[Cloudflare]** Configurar route `api.vulnerafix.com/vrm/*` o equivalente
- [ ] **[Daniel + Cloudflare]** Decidir: microservicio independiente vs. fusión con `lucky-bush-a6e2`

---

## Links de referencia

- Worker CF: `vrm-backend` — https://dash.cloudflare.com/
- D1 database `vulnerafix_db` UUID: `0a24b289-71e3-471e-bdcc-c6a1b524c1ca`
- Worker con auth completo (referencia): `lucky-bush-a6e2`
- Proyecto relacionado: vulnerafix.com — `C:/Users/aalvarez/Documents/vulnerafix-frontend/`
- Cloudflare Workers Docs: https://developers.cloudflare.com/workers/
- D1 Docs: https://developers.cloudflare.com/d1/
- Web Crypto API (PBKDF2): https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/deriveKey