Los nueve guards integrados de FLIN cubren los patrones de control de acceso más comunes: autenticación, roles, limitación de tasa, CSRF, claves API, listas blancas de IP, restricciones de tiempo, propiedad de recursos y filtrado de métodos. Pero las aplicaciones reales tienen requisitos de seguridad específicos del dominio que ningún framework puede anticipar de antemano.
Una aplicación SaaS necesita verificar niveles de suscripción. Una plataforma educativa necesita verificar el estado de inscripción. Una aplicación financiera necesita registro de auditoría en cada mutación. Un sistema multi-tenant necesita asegurar que los usuarios solo accedan a los datos de su propio tenant.
La sintaxis guard_definition de FLIN y el sistema de middleware permiten a los desarrolladores crear estas capas de seguridad personalizadas con la misma API declarativa que los guards integrados.
Definición de guards personalizados
La palabra clave guard_definition crea un nuevo tipo de guard que puede usarse en cualquier lugar donde se usen los guards integrados:
flin// Definir un guard personalizado
guard_definition verified_email {
user = request.user
if user == none || !user.emailVerified {
return response {
status: 403
body: { error: "Email verification required" }
}
}
}Use el guard personalizado exactamente como un guard integrado:
flinguard auth
guard verified_email
route POST {
// Solo usuarios autenticados con email verificado llegan aquí
}Guards personalizados parametrizados
Los guards personalizados pueden aceptar parámetros para comportamiento configurable:
flinguard_definition subscription(required_plan) {
user = request.user
if user == none {
return response {
status: 401
body: { error: "Authentication required" }
}
}
plan_levels = { "free": 0, "starter": 1, "pro": 2, "enterprise": 3 }
user_level = plan_levels[user.plan] || 0
required_level = plan_levels[required_plan] || 0
if user_level < required_level {
return response {
status: 403
body: {
error: "This feature requires the " + required_plan + " plan",
current_plan: user.plan,
required_plan: required_plan,
upgrade_url: "/pricing"
}
}
}
}
// Uso
guard auth
guard subscription("pro")
route POST {
// Solo usuarios pro y enterprise
}Composición de guards
Los guards personalizados se componen naturalmente con los guards integrados usando lógica AND:
flin// Seguridad máxima para operaciones financieras
guard auth
guard role("accountant", "admin")
guard verified_email
guard subscription("enterprise")
guard tenant_member
guard rate_limit(10, 60)
guard time("08:00", "18:00")
route POST {
// Este endpoint requiere:
// 1. Autenticación
// 2. Rol de contador o administrador
// 3. Dirección de email verificada
// 4. Suscripción enterprise
// 5. Membresía de tenant
// 6. Dentro del límite de tasa
// 7. Durante horario laboral
}Siete guards, siete líneas. Cada uno se evalúa en orden. Si alguno falla, la solicitud es rechazada con el código de estado y mensaje de error apropiados.
Esto concluye el Arco 10 -- las funciones de seguridad de FLIN. Diez artículos cubriendo cobertura OWASP Top 10, hashing de contraseñas Argon2, autenticación JWT, limitación de tasa, cabeceras de seguridad, 2FA, OAuth2, WhatsApp OTP, validación de entrada, pruebas de seguridad y guards personalizados. En el Arco 11, entramos en la parte más innovadora de FLIN: el motor de IA e intenciones, donde el lenguaje natural se encuentra con las consultas de base de datos.
Esta es la Parte 115 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [114] 75 pruebas de seguridad: cómo verificamos todo - [115] Guards y middleware de seguridad personalizados (estás aquí) - [116] El motor de intenciones: consultas de base de datos en lenguaje natural - [117] Búsqueda semántica y almacenamiento vectorial