APIDoc 4.0 ahora incluye un sistema de autenticación robusto que permite proteger la documentación de API con login obligatorio. Esta funcionalidad es ideal para APIs privadas que no deben ser accesibles públicamente.
apidoc.jsonapidoc.json{
"name": "Mi API Privada",
"version": "1.0.0",
"login": {
"active": true,
"admited": [
{ "email": "admin@company.com", "password": "secure123" },
{ "email": "dev@company.com", "password": "dev456" }
]
}
}
{
"login": {
"active": true,
"admited": [
{ "email": "admin@company.com", "password": "admin123" },
{ "email": "developer@company.com", "password": "dev456" }
],
"urlAuth": "https://api.company.com/auth/login",
"value_form": {
"email": "username",
"password": "password"
},
"response_success": 200,
"response_error": 401
}
}
{
"login": {
"active": true,
"urlAuth": "https://auth.company.com/api/login",
"value_form": {
"email": "email",
"password": "pass"
},
"response_success": 200,
"response_error": 400
}
}
| Parámetro | Tipo | Descripción | Requerido |
|---|---|---|---|
active |
boolean | Habilita/deshabilita el sistema de login | ✅ |
admited |
Array | Lista de usuarios locales válidos | ❌ |
admited[].email |
string | Email del usuario | ✅ (si se usa local) |
admited[].password |
string | Contraseña del usuario | ✅ (si se usa local) |
urlAuth |
string | URL de la API de autenticación remota | ❌ |
value_form |
Object | Nombres de campos del formulario remoto | ❌ |
value_form.email |
string | Nombre del campo email/usuario | ✅ (si se usa remoto) |
value_form.password |
string | Nombre del campo contraseña | ✅ (si se usa remoto) |
response_success |
number | Código HTTP de éxito (default: 200) | ❌ |
response_error |
number | Código HTTP de error (default: 400) | ❌ |
Edita tu archivo apidoc.json añadiendo la sección login con tus preferencias.
# Usando CLI
npx apidoc -i src/ -o docs/
# Usando programáticamente
const { createDoc } = require('@hrefcl/apidoc');
createDoc({
src: ['./src'],
dest: './docs'
});
docs/index.html en el navegadorEl formulario de login respeta automáticamente el tema oscuro/claro y usa Tailwind CSS. Los estilos se integran perfectamente con el diseño existente.
Los errores se muestran de forma clara y accesible:
localStoragenode test-login.js
Este script:
Email: odin@href.cl
Password: 1234
Email: thor@href.cl
Password: 1234
template/src/components/
├── auth.ts # Sistema de autenticación
├── content-protection.ts # Encriptación de contenido
└── sidebar.ts # Componentes UI
lib/core/
└── auth-processor.js # Procesador de autenticación
template/
└── index.html # Template con soporte de login
// Inicializar sistema de auth
authManager.init(loginConfig);
// Verificar autenticación
const isAuth = authManager.isAuthenticated();
// Hacer login
const result = await authManager.login(email, password);
// Logout
authManager.logout();
// Encriptar contenido
const encrypted = ContentProtection.encryptContent(html, key);
// Desencriptar contenido
const decrypted = ContentProtection.decryptContent(encrypted, key);
// Proteger secciones sensibles
const { protectedHtml, encryptedSections } =
ContentProtection.protectSensitiveSections(html, key);
crypto-js: Para encriptación AEStailwindcss: Para estilos del formulario// server.js - Servir documentación protegida
app.use('/api-docs', express.static('docs', {
setHeaders: (res, path) => {
if (path.endsWith('index.html')) {
res.setHeader('Cache-Control', 'no-cache');
}
}
}));
# nginx.conf - Headers de seguridad
location /api-docs {
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy strict-origin-when-cross-origin;
try_files $uri $uri/ /api-docs/index.html;
}
# Dockerfile - Servir documentación protegida
FROM nginx:alpine
COPY docs/ /usr/share/nginx/html/
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
login.active = true en apidoc.jsonlogin.active = trueEl sistema de login de APIDoc 4.0 proporciona una solución robusta y flexible para proteger documentación de API. Combina la simplicidad de configuración con seguridad avanzada, siendo ideal para equipos que necesitan controlar el acceso a su documentación técnica.
La arquitectura de encriptación client-side garantiza que el contenido permanezca protegido incluso en hosting estático, mientras que la flexibilidad de autenticación dual permite adaptarse a diferentes infraestructuras organizacionales.