Probar la conexión y seguridad

Un datasource guarda la llave de una base de datos de verdad — muchas veces, de producción. Esta página cubre los dos lados de esa responsabilidad: cómo confirmar que la conexión funciona antes de guardar, y qué hace la plataforma (y qué se niega a hacer) con las credenciales después.

#Probar la conexión

El botón Probar conexión está en el formulario de creación y en el modal Editar conexión, junto a las acciones de guardar:

1. Rellena los campos de conexión.
2. Pulsa Probar conexión. El botón pasa a Probando….
3. La plataforma abre una conexión de verdad a la base de datos, ejecuta una consulta inofensiva de verificación, y cierra la conexión. Nada se escribe ni se cambia.
4. El éxito muestra la confirmación «Conexión OK.»; el fallo muestra una alerta con el mensaje devuelto por el motor de la base de datos — tal cual, porque es él el que dice qué corregir.

Dos casos particulares:

• Al editar con la contraseña en blanco, la prueba usa la contraseña guardada — es decir, prueba la conexión tal como va a quedar después de guardar.
• En un SQLite por crear no hay botón — el archivo aún no existe, y una prueba ahí solo podría mentir. Aparece después de guardar.

#La prueba falló — ¿y ahora?

El mensaje viene del motor, por eso varía; los patrones, no:

Síntoma	Qué verificar
Tarda y acaba en timeout	¿Host y Puerto correctos? ¿El servidor acepta conexiones desde la máquina donde corre la plataforma (firewall, red)?
Error de autenticación / login failed	Usuario y Contraseña. En algunos motores, también si esa cuenta puede conectarse desde otra máquina.
Base de datos desconocida	El campo Database tiene el nombre exacto de la base dentro del servidor.
Errores de SSL/TLS en un SQL Server 2008/2012	Activa TLS legado (SQL Server antiguo) — es exactamente para esto.
Errores de certificado en otros motores	Usar SSL / Encrypt según el servidor exija; en servidores internos con certificado propio, Trust server certificate.
Oracle no encuentra el servicio	¿La Connect string sigue host:port/service_name? ¿El service_name es el del servicio, no el SID?

#Credenciales que nunca vuelven a la pantalla

La contraseña de un datasource es de escritura única: entra en el formulario, y a partir de ahí la plataforma no vuelve a mostrarla — a nadie, nunca, ni a quien la escribió.

• Al abrir Editar conexión, todos los campos vienen rellenos excepto la contraseña. El campo se llama Contraseña (vacío = mantener): en blanco, la actual continúa; relleno, la sustituye.
• No existe ninguna pantalla, exportación o permiso que devuelva la contraseña en claro. Si la pierdes, redefínela en el servidor de la base de datos y escribe la nueva aquí.
• En reposo, las credenciales quedan cifradas — como dicen los propios formularios: «Todo se cifra en reposo.»

#¿Y cuando la app viaja?

Al exportar una app (Ajustes → Exportar app), eliges el destino de los secretos:

• Sin secretos (recomendado) — «Las conexiones de los datasources y los secrets van por rellenar». Quien importe en otra instancia vuelve a rellenar las credenciales — las contraseñas no viajan.
• Con secretos, protegidos por passphrase — los valores van cifrados con una passphrase que defines y que se pedirá al importar. «Sin la passphrase, los secretos del paquete son irrecuperables.»

#Quién puede hacer qué

Acción	Perfil necesario en la app
Ver la lista de datasources y usar la app	Developer
Crear, editar, renombrar, eliminar datasources	Administrador
Consola SQL, crear/cambiar objetos (DDL)	Administrador

Por esto un developer puede no ver el botón Añadir datasource ni el menú Editar conexión — no es un error, es el perfil.

#Todo queda registrado

• Historial de la app — cada creación, cambio, renombrado y eliminación de un datasource entra en el historial de cambios («Datasource "crm" creado», «Datasource "crm" cambiado», …), con autor y fecha.
• Auditoría de la plataforma — las mismas operaciones quedan en la pista de auditoría del Radar, con el objetivo Datasource.
• Consola SQL — cuando ejecutas SQL que escribe o cambia (un UPDATE, un DROP…), el evento se audita con el tipo de operación y una huella digital de la query — sin el texto del SQL, para que los datos sensibles escritos en la consola no acaben en el registro.
• Radar → Estado — la sección Conexiones a bases de datos muestra las conexiones configuradas en todas las apps. Y con una cautela deliberada: «Esta página no se conecta a ninguna de ellas por sí sola: son bases de datos de producción, y abrir conexiones en cada visita es tráfico que nadie pidió.»

#Buenas prácticas

• Cuenta dedicada, privilegios mínimos. Crea en la base de datos un usuario solo para la app, con acceso únicamente a las tablas necesarias. Todo lo que la app ejecuta — APIs, scripts, consola — pasa por esa cuenta.
• Apunta las pruebas a datos de prueba. Al probar una API que escribe, la propia plataforma avisa: «La prueba corre el pipeline de verdad contra los datasources — una mutation hace escrituras reales. Confirma que estás apuntando a datos de prueba.»
• Cifra la conexión siempre que el servidor lo permita (Usar SSL / Encrypt) — en especial cuando la base de datos está en otra red.
• Nombres que digan el entorno. crm y crm-teste evitan el peor engaño posible: escribir en el sitio correcto del entorno equivocado.

#Preguntas frecuentes

• ¿Keplin me muestra la contraseña que guardé? No. Es de escritura única — la alternativa es sustituirla.
• ¿Probar conexión toca los datos? No. Abre la conexión, corre una consulta de verificación inofensiva y la cierra.
• ¿Por qué la prueba pasa pero la query de la API falla? La prueba valida la conexión, no los privilegios sobre cada tabla. Si la cuenta no puede leer o escribir en una tabla, es en esa query donde el error aparece.
• Cambié la contraseña en el servidor de la base de datos — ¿y ahora? Las APIs y scripts empiezan a fallar con error de autenticación. Abre Editar conexión, escribe la contraseña nueva y Guardar.