Panel klienta WaveHost
Panel de cliente de un proveedor de hosting: pedido y gestión de VPS y servidores dedicados, monedero, facturas y programa de referidos. Un stack moderno con autenticación segura y conexión al panel de juegos mediante un handshake seguro. El cliente gestiona todo desde un solo lugar.
El panel de cliente de un proveedor de hosting: pedir y gestionar VPS y servidores dedicados, un monedero, facturas y un programa de referidos. La parte más interesante es el enlace seguro con un panel de juegos aparte, para que un cliente no inicie sesión dos veces y las cuentas se conecten sin riesgo de vincular una ajena - mediante un handshake HMAC firmado.
Introducción
WaveHost es un proveedor de hosting que necesitaba un único lugar para sus clientes: pides un servidor, pagas, refieres a otros, todo desde el mismo panel. Esa parte por sí sola es trabajo artesanal que ya habíamos hecho antes. El verdadero desafío estaba al lado: en el proveedor ya funcionaba un panel de juegos aparte con sus propias cuentas, y esos dos mundos había que unirlos para que el cliente sintiera un solo sistema, y no dos.
Lo más sencillo sería hacer que la gente inicie sesión dos veces y vincular una cuenta a mano por correo. Pero ese es un camino directo a los errores, y con la vinculación de cuentas un error tiene un precio concreto: vinculas a alguien una cuenta ajena y tienes un problema que un simple lo siento no puede deshacer. Queríamos un enlace en el que se pueda confiar. Este caso de estudio trata sobre todo de ese enlace.
Todo desde un solo lugar
El fundamento del panel es la gestión a la que el cliente vuelve a diario. El pedido y la gestión de servidores abarcan tanto los VPS como las máquinas dedicadas, con su estado y configuración visibles en una sola vista. El cliente no salta entre herramientas para comprobar qué tiene y en qué estado está.
Alrededor de eso vive el resto de la gestión. El monedero y las facturas están uno junto a otras, de modo que el saldo, los pagos y los documentos forman un todo, y no tres pestañas separadas que hay que conciliar uno mismo. El programa de referidos añade un enlace de referido y un flujo de comisiones claro, enganchado al mismo monedero. Todo se apoya en una stack moderna con autenticación segura, porque este es un panel donde hay dinero y accesos a servidores.
Un inicio de sesión en lugar de dos
El núcleo del proyecto es unir el panel de cliente con el panel de juegos existente. Desde el lado del cliente el problema es banal e irritante a la vez: dos cuentas, dos inicios de sesión, dos mundos que no le importan, porque él simplemente quiere gestionar todo en un solo lugar. Desde el lado de la ingeniería, esa es justo la parte en la que es fácil hacer algo peligroso.
La solución ingenua dice: que el cliente indique su usuario del panel de juegos y nosotros lo vinculamos. El problema es que de ese modo cualquiera podría indicar el usuario de otro y vincularse a una cuenta que no es suya. La vinculación manual por correo es lenta e igual de porosa. Necesitábamos una forma en la que un sistema le demuestre al otro la identidad del cliente, sin confiar en nada que pase por el navegador.
Un apretón de manos firmado
La solución es un handshake basado en HMAC. Cuando el cliente hace clic en "vincular cuenta" en el panel de WaveHost, el panel genera un enlace que lleva el identificador del usuario, una marca de tiempo y una firma calculada con un secreto que solo conocen los dos paneles. El panel de juegos recibe ese enlace, recalcula la firma con su propio secreto y compara. Si coincide, sabe que la petición vino de verdad del panel de WaveHost y no de alguien que falsificó la URL.
Lo que importa es lo que el navegador nunca ve. El secreto no sale de los servidores, así que ni siquiera alguien que observe o intercepte el enlace puede calcular una firma válida para un identificador ajeno. La marca de tiempo cierra la segunda brecha: el enlace es de corta duración, y el panel de juegos simplemente rechaza un token caducado, así que un enlace espiado no se puede usar más tarde.
El enlace que vincula las cuentas lleva una firma HMAC y una marca de tiempo. El panel de juegos rechaza un token caducado o con una firma incorrecta, así que un enlace interceptado o falsificado no vinculará una cuenta ajena. El secreto lo conocen solo una y otra parte, nunca el navegador, y por eso la comodidad no se puede canjear por una brecha.
Por qué un enlace falsificado no funcionará
Vale la pena desglosarlo en escenarios, porque solo entonces se ve que la comodidad de verdad no cuesta seguridad. Alguien sustituye el identificador del enlace por otro, para vincularse a una cuenta que no es suya. La firma deja de coincidir, porque se calculó para un identificador distinto, y una nueva no se puede generar sin el secreto. El panel de juegos rechaza la petición.
Segundo escenario: alguien intercepta el enlace válido de un cliente e intenta usarlo. Aquí salva el día la marca de tiempo. El enlace vive poco, así que interceptado a destiempo ya no vale nada, y el panel de juegos trata un token caducado exactamente igual que uno falsificado. En ambos casos la frontera se comprueba del lado del servidor, a la entrada, y no en la interfaz, que siempre se puede eludir.
Antes y después de unir los paneles
| Aspecto | Paneles separados | Después de la unión por HMAC |
|---|---|---|
| Inicios de sesión | dos | uno |
| Vinculación de cuenta | manual por correo | un clic |
| Riesgo de vincular una ajena | real | rechazado por la firma |
| Secreto en el navegador | - | nunca |
Qué aporta realmente el producto terminado
El cliente lleva toda la gestión desde un solo lugar. Pide servidores, gestiona VPS y máquinas dedicadas, paga, refiere a otros y vigila el monedero sin saltar entre herramientas. El enlace con el panel de juegos funciona con un clic en lugar de con un intercambio de correos, así que los dos sistemas del proveedor se sienten como uno para el cliente.
Por debajo, esa comodidad no se paga con seguridad, porque el handshake es de corta duración y firmado y el secreto nunca llega al navegador. Un enlace falsificado o interceptado no vinculará una cuenta ajena, porque el servidor guarda la frontera a la entrada, y no la interfaz. Este es exactamente el tipo de solución de la que trataba el proyecto: simple para el cliente, duro donde tiene que ser duro.
Más proyectos
Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.
¿Tiene un proyecto similar?
Escríbenos - el presupuesto es gratuito y llega en una hora.




