Diego Molinari

← Todos los casos

El navegador no sabe dónde están las figuras

El problema

Un concurso: la persona se registra, juega, y si gana queda habilitada para el sorteo de premios.

En cuanto hay un premio de por medio, la pregunta deja de ser «¿anda el juego?» y pasa a ser «¿puedo confiar en que ganó?». Un memotest hecho del lado del navegador tiene el tablero completo en la página: quién quiera puede abrir las herramientas de desarrollo, ver dónde está cada par, y ganar todas las veces que quiera. También puede saltearse el juego entero y decirle al servidor «gané».

Qué construí

Una landing con formulario de registro, un memotest de 3×3 —cuatro pares y una tarjeta roja que hace perder—, y un panel de administración donde se cargan las marcas auspiciantes y se edita el texto de las bases y condiciones sin tocar código.

Ganar una vez habilita a la persona para el sorteo, de forma permanente: perder después no le saca esa habilitación.

La decisión que ordenó todo

El tablero nunca llega al navegador. El estado de la partida viaja cifrado en una cookie que el cliente lleva y trae pero no puede leer ni modificar. El navegador manda un número: qué casillero tocó. El servidor descifra el estado, resuelve qué había ahí y devuelve el tablero como quedó.

Qué sabe cada lado

Juego en el navegador

La página tiene el tablero

  • Las figuras están en la memoria de la página.
  • El resultado lo calcula el cliente y lo informa.
  • Mirar dónde están los pares es abrir una pestaña.

Juego en el servidor

La página no tiene nada

  • El navegador manda el número del casillero.
  • El servidor decide qué había y si ganó.
  • No hace falta prohibir la trampa: no hay con qué hacerla.
No es una validación agregada arriba del juego. Es que la información necesaria para hacer trampa no está del lado donde se haría.

Las decisiones que costaron

La cookie está cifrada, y además atada. Que no se pueda leer no alcanza: alguien podría guardar la cookie de una partida ganada y volver a usarla. Antes de resolver la jugada, el servidor verifica que ese estado pertenezca a este participante y a esta partida. Si no coincide, no hay jugada.

El registro se verifica del lado del servidor. La validación del formulario en el navegador es comodidad para la persona, no seguridad: se saltea con una petición directa. La verificación anti-bot se comprueba en el servidor, que es el único lugar donde la respuesta significa algo.

Las bases se editan desde el panel. Un concurso cambia sus condiciones y publicarlas no puede depender de un despliegue. Se editan desde la administración y quedan publicadas al instante.

Vista ilustrativa · partida de ejemplo

concurso · jugar

Qué viaja

El navegador manda

{ "cellIndex": 4 }

El servidor responde

{ "tablero": [...],
  "pares": 2,
  "estado": "en juego" }

Nunca viaja dónde están las figuras que todavía no se destaparon.

Reconstrucción ilustrativa, no una captura. Dos pares encontrados y una tarjeta recién dada vuelta. Lo que importa está a la derecha: el navegador sólo dice qué casillero tocó. El contenido de los casilleros cerrados no está en la página, así que no hay nada que espiar.

Resultado

El concurso corre con registro verificado, juego resuelto en el servidor y habilitación para el sorteo. Las marcas auspiciantes y las bases se administran desde el panel, sin desplegar.