Prueba el portal y revisa cada dato guardado.
La versión 1.0.0 es un portal de auto-declaración por fecha, no verificación de identidad. Reproduce la decisión, revisa la UI y el registro reales y decide si encajan un umbral global y borrado manual.

- 1.0.0
- paquete exacto verificado con SHA-256
- PS ≥ 8.0
- mínimo declarado por el código entregado
- 1
- umbral global; sin reglas por país
- 1–365
- días de cookie; retención de logs separada
Elige el modelo de evidencia antes del módulo.
Decide la confianza necesaria
Compara una fecha escrita con un umbral. No establece identidad ni quién la introdujo.
Elige un alcance del catálogo
Cubre toda la tienda o introduce IDs. No existe rama por país, dirección o GeoIP.
Gestiona el registro del servidor
Aprobados y fallidos guardan año e identificadores de red/navegador con hash. No hay purga automática.
Prueba checkout y SEO
El checkout restringido vuelve al carrito. No hay bypass: controladores, teclado y HTML requieren pruebas exactas.
Reproduce el portal sin enviar datos personales.
Usa una fecha inventada. El simulador reproduce edad, alcance, cookie y checkout y muestra el registro.
- Edad calculada
- 24
- Portal en esta superficie
- Visible
- Cookie de decisión
- Se crearía por 30 días
- Checkout
- Sin redirección en este estado
Registro del navegador
Token first-party HttpOnly np_age_verified; Secure solo HTTPS; sin SameSite explícito.
Registro del servidor
Evento para este estado: verify / passed / birth_year 2002
Columnas de la tabla entregada
id_shop · id_customer · id_cart · event_type · result · rule_context · minimum_age · birth_year · ip_hash · user_agent_hash · date_add
La versión 1.0.0 no purga registros. Los días de cookie no borran filas del servidor.
Solo simulador del producto. No determina edad, evidencia, base, retención ni control de entrega aplicable.
Los datos permanecen en este navegador y nunca se envían. Usa solo ejemplos inventados.
Sigue el recorrido entregado desde la tienda hasta los ajustes.
1. Bloquea la superficie configurada
La superposición real bloquea el scroll, retiene el foco y permite confirmar o salir. El fondo no la cierra.
Abrir esta escena exacta →
2. Envía día, mes y año
El endpoint same-origin comprueba fecha y edad. Aprobar crea la cookie; aprobados y fallidos incluyen el año en el registro.
Abrir esta escena exacta →
3. Configura solo lo que entrega la versión 1.0.0
Este HelperForm real muestra controles exactos: activar, alcance, una edad, días, IDs, título, mensaje y salida.
Abrir esta escena exacta →
«Sin llamada externa» no significa «sin registro del servidor».
| Ubicación | Datos exactos 1.0.0 | Límite operativo |
|---|---|---|
| Cookie del navegador | np_age_verified: token SHA-256 determinista derivado de clave, módulo y edad. | HttpOnly; Secure solo con HTTPS; 1–365 días; sin SameSite explícito. Cambiar la edad invalida el valor. |
| Fila del servidor | IDs tienda/cliente/carrito; evento, resultado, contexto, edad, año, hash IP/user-agent y fecha. | El año se guarda en aprobados y fallidos. El hash por sí solo no anonimiza. |
| Operación de retención | Sin ajuste de retención, purga programada ni interfaz de borrado por fila. | El comercio debe operar el borrado aparte. Desinstalar elimina toda la tabla; no es una política normal. |
Aplica necesidad, proporcionalidad y minimización antes de activar.
El Comité Europeo de Protección de Datos distingue la auto-declaración de métodos más fuertes, exige un enfoque proporcional al riesgo y señala que su fiabilidad depende principalmente de la buena fe. También pide finalidad, minimización, retención transparente y seguridad. Esta página aplica esos principios al paquete; no es asesoría legal.
Leer la Declaración 1/2025 del EDPB ↗Necesidad primero
Documenta por qué se necesita la decisión para producto, ruta y público concretos.
Confianza proporcional
Ajusta el método al riesgo y evidencia. La auto-declaración es el modelo de menor confianza aquí.
Minimiza y limita la finalidad
Evalúa si año, IDs y hashes son necesarios; no reutilices el registro para perfiles.
Define un borrado real
La versión 1.0.0 no impone duración. Asigna responsable, calendario, evidencia y respuesta fuera del módulo.
Un portal simple solo sirve si una evidencia simple basta.
Encaje posible · una regla revisada
Solo después de corregir y volver a probar el defecto de fechas futuras: un umbral basta, una revisión acepta fecha escrita y el comercio gestiona aviso, registro y borrado.
Encaje condicionado · IDs y checkout personalizado
IDs, categorías y controladores pueden cambiar. Continúa solo tras probar cada ruta en el clon.
No encaja · país o identidad verificada
Usa otro proceso para país, dirección, documentos, biometría, tokens, entrega, no-log o retención automática.
Demuestra los fallos antes de ponerlo delante del catálogo.
| Decisión o riesgo | Qué hace la versión 1.0.0 | Qué debe probar el comercio |
|---|---|---|
| Límite del umbral | El formulario limita el año; el servidor valida la fecha y compara DateTime::diff()->y con una edad. | Prueba antes/día/después del cumpleaños, 29 de febrero, fecha inválida y futura. |
| Solicitud directa con fecha futura · defecto 1.0.0 | JavaScript rechaza años futuros, pero el endpoint no. El componente absoluto puede aprobar una fecha futura lejana. | No dependas de esta versión en producción hasta que el endpoint rechace fechas posteriores a hoy y pasen pruebas directas. |
| El alcance se desajusta | Los IDs proceden de listas manuales. | Mueve productos, prueba combinaciones y rutas no restringidas. |
| Controlador de checkout no reconocido | El bloqueo reconoce algunos controladores core y el carrito. | Prueba checkout clásico/one-page, botones rápidos, restauración y controladores. |
| Casos límite de cookie/sesión | El token cambia con la edad; Secure depende de HTTPS. | Prueba HTTPS, subdirectorio, caducidad, cambio de edad, privado y cookies bloqueadas. |
| El registro crece sin límite | Cada evento inserta una fila; no hay borrado programado. | Demuestra trabajo externo, permisos, copias, alertas y conteo tras el plazo. |
| La modal perjudica acceso o descubrimiento | Existen focus trap y data-nosnippet; no hay bypass ni garantías. | Usa teclado/lector; revisa HTML, enlaces, robots y Search Console. |
Antes de publicar el portal
¿Es verificación de identidad?+
No. El visitante escribe una fecha. No comprueba documentos, biometría, credenciales o entrega ni sabe quién la introdujo.
¿Tiene edades por país o GeoIP?+
No. Tiene una edad global. País, dirección y GeoIP no participan en la decisión.
¿Puedo depender del endpoint 1.0.0 en producción?+
No antes de corregirlo. El formulario rechaza años futuros, pero el endpoint no rechaza por sí mismo una fecha posterior a hoy. Como usa el componente absoluto de DateTime::diff(), una solicitud directa puede aprobar. Corrige el servidor y añade pruebas directas.
¿Guarda la fecha completa?+
La tabla no tiene día ni mes, pero aprobados/fallidos guardan birth_year con IDs, hashes y fecha. La fecha completa se envía al endpoint.
¿Puedo configurar la retención?+
No en 1.0.0. No hay ajuste, purga ni pantalla de borrado. Hace falta un proceso separado.
¿Funciona con cualquier checkout y tema?+
No se garantiza. Declara PrestaShop 8.0.0 como mínimo, pero controladores, overrides, one-page, pagos, CSS y consentimiento requieren staging.
¿Comprar el módulo establece cumplimiento?+
No. Regla, evidencia, base, aviso, retención, accesibilidad y entrega dependen del contexto. Obtén revisión independiente.
Mantén juntos simulador, evidencia del paquete y compra.
Abre la página del producto para ver SHA-256, tres escenas reales, instalación y licencia de 49 € de pago único. Compra solo tras revisar y probar auto-declaración, registros y retención.