GamerCreador
Admin
SUPER VIP
Leyenda
Referente
Mentor
Especialista
Creador
Colaborador
Participante
Explorador
- Desde
- 1 Oct 2019
- Mensajes
- 2,382
- Reacciones
- 2,158
- Honor
- 829
- Creador del tema
- #1
El ranking ya funciona: el juego manda una puntuación y aparece en la lista. La siguiente prueba merece hacerse antes de abrirlo al público: ¿qué ocurre si el cliente manda otra cifra o repite el mismo resultado?
Un cliente modificado puede fabricar peticiones. Autenticar al jugador identifica quién llama, pero no demuestra que haya conseguido los puntos. Por eso conviene decidir qué evidencia tendrá el backend para aceptar una marca.
Propuesta conceptual: comprueba identidad, permisos y evidencia antes de actualizar el resultado.
1. Define qué competición estás ofreciendo
La documentación de Godot recuerda que las API de red no hacen segura la lógica automáticamente y recomienda validar la información del cliente: diseño multijugador seguro.
2. Diseña el envío alrededor de la partida
Como propuesta de arquitectura, registra en el backend un identificador de partida, sus participantes, sus reglas y su estado. Al terminar, procesa el resultado asociado a esa partida y a la identidad autenticada. No permitas que un campo player_id del cuerpo de la petición decida por sí solo quién recibe los puntos.
Comprueba permisos sobre cada partida o recurso, además de comprobar que existe una sesión válida. OWASP documenta este problema como autorización a nivel de objeto.
3. Trata los reintentos como algo normal
Imagina que el servidor guarda una victoria, pero la respuesta se pierde. El cliente reintenta. Si cada petición suma puntos, la misma partida contará dos veces aunque nadie esté intentando hacer trampas.
Mi propuesta de implementación es guardar una operación única por partida, jugador y tipo de recompensa, y actualizar la recompensa de forma atómica con ese registro. Si llega otra petición idéntica, devuelve el resultado ya guardado. Si reutiliza la misma clave con datos diferentes, recházala y registra el conflicto.
Si el resultado y la recompensa están en servicios distintos, necesitarás coordinar los reintentos entre ellos, por ejemplo con una cola y consumidores idempotentes. Una comprobación «si no existe, insertarlo» sin control de concurrencia puede fallar cuando llegan dos peticiones a la vez.
4. Si usas Nakama, revisa este ajuste
Un leaderboard autoritativo impide que el cliente escriba puntuaciones directamente: las escrituras pasan por el runtime del servidor. Debes activarlo al crear la clasificación. Referencia de leaderboards.
Eso delimita quién puede escribir, pero tu función del servidor todavía tiene que validar el resultado. Una RPC que copie sin comprobar la puntuación del cliente sigue aceptando números inventados. Elige también si guardas la mejor marca, reemplazas la anterior o acumulas puntos; no son comportamientos equivalentes. Modelo y operadores de puntuación.
Reintentar la misma operación no debe volver a conceder la recompensa; los datos contradictorios requieren rechazo.
Una batería de pruebas para tu propio entorno de desarrollo
Guarda el motivo de los rechazos sin registrar tokens ni secretos. Una marca sospechosa puede merecer revisión, pero evita convertir cualquier anomalía en una expulsión automática.
¿Tu juego calcula el resultado en un servidor o permite partidas offline? Esa diferencia cambia mucho el diseño del ranking.
Un cliente modificado puede fabricar peticiones. Autenticar al jugador identifica quién llama, pero no demuestra que haya conseguido los puntos. Por eso conviene decidir qué evidencia tendrá el backend para aceptar una marca.
Propuesta conceptual: comprueba identidad, permisos y evidencia antes de actualizar el resultado.
1. Define qué competición estás ofreciendo
- Partidas controladas por un servidor: calcula allí el resultado a partir del estado que el servidor valida.
- Juego offline con subida posterior: asume que validar el resultado es más difícil. Puedes comprobar límites o verificar una repetición si tu diseño lo permite, pero un número plausible no demuestra una partida legítima.
- Ranking informal entre amigos: quizá aceptes menos garantías para simplificar. Conviene que esa decisión sea consciente antes de añadir premios o una clasificación pública.
La documentación de Godot recuerda que las API de red no hacen segura la lógica automáticamente y recomienda validar la información del cliente: diseño multijugador seguro.
2. Diseña el envío alrededor de la partida
Como propuesta de arquitectura, registra en el backend un identificador de partida, sus participantes, sus reglas y su estado. Al terminar, procesa el resultado asociado a esa partida y a la identidad autenticada. No permitas que un campo player_id del cuerpo de la petición decida por sí solo quién recibe los puntos.
Comprueba permisos sobre cada partida o recurso, además de comprobar que existe una sesión válida. OWASP documenta este problema como autorización a nivel de objeto.
3. Trata los reintentos como algo normal
Imagina que el servidor guarda una victoria, pero la respuesta se pierde. El cliente reintenta. Si cada petición suma puntos, la misma partida contará dos veces aunque nadie esté intentando hacer trampas.
Mi propuesta de implementación es guardar una operación única por partida, jugador y tipo de recompensa, y actualizar la recompensa de forma atómica con ese registro. Si llega otra petición idéntica, devuelve el resultado ya guardado. Si reutiliza la misma clave con datos diferentes, recházala y registra el conflicto.
Si el resultado y la recompensa están en servicios distintos, necesitarás coordinar los reintentos entre ellos, por ejemplo con una cola y consumidores idempotentes. Una comprobación «si no existe, insertarlo» sin control de concurrencia puede fallar cuando llegan dos peticiones a la vez.
4. Si usas Nakama, revisa este ajuste
Un leaderboard autoritativo impide que el cliente escriba puntuaciones directamente: las escrituras pasan por el runtime del servidor. Debes activarlo al crear la clasificación. Referencia de leaderboards.
Eso delimita quién puede escribir, pero tu función del servidor todavía tiene que validar el resultado. Una RPC que copie sin comprobar la puntuación del cliente sigue aceptando números inventados. Elige también si guardas la mejor marca, reemplazas la anterior o acumulas puntos; no son comportamientos equivalentes. Modelo y operadores de puntuación.
Reintentar la misma operación no debe volver a conceder la recompensa; los datos contradictorios requieren rechazo.
Una batería de pruebas para tu propio entorno de desarrollo
- Enviar un resultado válido y comprobar una sola actualización.
- Repetirlo y comprobar que no duplica puntos ni recompensas.
- Enviar dos copias simultáneamente y comprobar el mismo resultado.
- Usar la cuenta de prueba B con una partida de A y comprobar que se rechaza.
- Enviar una partida inexistente, caducada o ya cerrada con otro resultado.
- Interrumpir la respuesta y reintentar después.
Guarda el motivo de los rechazos sin registrar tokens ni secretos. Una marca sospechosa puede merecer revisión, pero evita convertir cualquier anomalía en una expulsión automática.
¿Tu juego calcula el resultado en un servidor o permite partidas offline? Esa diferencia cambia mucho el diseño del ranking.
