Seguridad
Vas a confiarnos la facturación, los datos de tus huéspedes y la dirección de tus clientes. Esta página dice lo que está hecho y, al final, lo que falta — porque la segunda lista dice más de nosotros que la primera.
Aislamiento
La mayoría de las plataformas meten a todos los clientes en las mismas tablas y los separan mediante una columna. Basta una consulta escrita deprisa, sin el filtro, para que un cliente vea los datos de otro. Aquí esa consulta no tiene nada que ver.
Lo habitual
WHERE tenant_id = ?
Todos los clientes en las mismas tablas. La separación es un filtro que alguien tiene que acordarse de escribir, en cada consulta, para siempre. Olvidarlo una vez basta.
Aquí
USE ajja_tenant_…
Cada cliente en su propia base de datos. La consulta sin filtro devuelve igualmente solo lo que es tuyo, porque la conexión ya se apuntó a tu lado antes de que la consulta existiera.
ajja_tenant_<slug>
DROP DATABASE
quién eres · qué contratas · qué módulos
Cuentas y accesos
Cada una de estas comprobaciones se ejecuta en el servidor. Ninguna depende de lo que el navegador decida mostrar u ocultar.
Autenticación en dos pasos con la aplicación que ya usas. El secreto solo pasa a valer después de que confirmes un código generado con él, para que nadie se quede fuera por haber leído mal el QR. Recibes 8 códigos de recuperación, y tanto ellos como el secreto se guardan cifrados en la base de datos.
Entre la contraseña correcta y el código del móvil hay un tique temporal que dura cinco minutos. Pasado ese tiempo se vuelve al principio — no queda un medio inicio de sesión abierto esperando.
El inicio de sesión tiene un tope por correo electrónico y por dirección a la vez: cinco intentos por minuto para el mismo par, veinte por minuto para la misma dirección. Contar solo el correo permitiría a un desconocido bloquearte la cuenta fallando a propósito. La verificación en dos pasos, el registro y los formularios públicos de check-in y de reserva también tienen tope. La API ya autenticada está limitada a 120 peticiones por minuto y por usuario, no por dirección — dos compañeros en la misma oficina no comparten el presupuesto el uno del otro.
Ocultar un elemento del menú no es seguridad. Cada dirección pasa por dos comprobaciones separadas — el módulo está activo en este cliente, y tu rol ve ese módulo — y responde 403 incluso a quien escriba la dirección a mano.
Un token válido, apuntado al nombre de otro cliente, no lee nada. Y la respuesta es 404, no 403: quien anda probando nombres de clientes no llega a saber cuáles existen.
El huésped y el propietario entran por un enlace con clave propia, que abre una sola cosa y puede tener caducidad. No hay cuenta que robarles ni contraseña que reutilicen en otro sitio.
Una petición, de principio a fin
Esto es lo que ocurre entre que pulsas un botón y aparece el resultado. El orden está fijado en el arranque de la aplicación, no dejado al azar de cómo se escribió cada ruta — porque una comprobación que se ejecuta demasiado tarde ya ha dejado que la petición empiece a trabajar.
El dominio propio, el subdominio o la cabecera de la petición dicen a qué cliente pertenece. Nombre desconocido, aquí termina.
Un espacio de trabajo suspendido no se sirve, ni siquiera para lectura.
La conexión a la base de datos pasa a apuntar a la de ese cliente. Todo lo que venga después, errores incluidos, solo alcanza este lado.
Se comprueba el token. Sin un token válido no hay paso cinco.
120 por minuto, contadas por usuario. Por encima de eso, el servidor dice que basta.
El usuario del token y el cliente de la petición tienen que ser el mismo. Es esta unión la que impide que un token legítimo lea la casa de al lado.
El módulo tiene que estar activo en el cliente y visible para tu rol. Dos comprobaciones, no una.
Solo después de estas siete es cuando los números de la dirección se transforman en registros — y siempre a partir de la base de datos que eligió el paso tres.
Lo que queda registrado
Un sistema que no registra nada te obliga a creer. Preferimos que puedas comprobarlo.
autor · acción · objetivo · antes/después
Las acciones administrativas de peso — suspender un cliente, tocar el precio de un plan, desactivar un cupón — guardan quién las hizo, sobre qué, y el valor antes y el valor después. Se escribe en cada uso, a propósito: lo que una máquina hace por sí sola, como un pago que se confirma, no es acción de nadie y no entra en esta lista.
tenant.impersonated
El soporte puede entrar en tu cuenta para resolver un problema. Eso queda registrado con nombre y hora, y mientras dure tienes una barra en la parte superior de la pantalla que indica que está ocurriendo. No es silencioso.
tipo · contenido · estado · error
Cada evento de pago recibido guarda el tipo, el contenido, el estado y el mensaje de error si falló. El mismo evento repetido se reconoce y no se cuenta dos veces.
sin cuerpo de la petición
Cuando algo falla, guardamos el mensaje, el archivo, la línea y la dirección que falló. El cuerpo de la petición no se guarda — para investigar un error no hace falta quedarse con la factura que ibas a guardar.
Los datos son tuyos
Una plataforma que dificulta la salida está confesando que no puede retenerte de otra manera.
una petición, un archivo
sin penalización
Qué sale
Lo que todavía no tenemos
Nada de esto está prometido ni contratado. Está aquí para que sepas lo que estás comprando hoy.
Exportar está hecho. Borrar los datos de un solo individuo, manteniendo el resto, sigue siendo trabajo manual — la única eliminación automática es la del cliente entero.
Si vas a confiarnos datos de terceros, tienes derecho a respuestas concretas antes de firmar. Crea la cuenta y pregunta, o pregunta primero.
14 días gratis, con la tarjeta validada sin cobro. Cancelas antes del 15.º día tras la suscripción y no pagas nada.