Testar a ligação e segurança

Um datasource guarda a chave de uma base de dados de verdade — muitas vezes, de produção. Esta página cobre os dois lados dessa responsabilidade: como confirmar que a ligação funciona antes de gravar, e o que a plataforma faz (e recusa fazer) com as credenciais depois.

#Testar a ligação

O botão Testar ligação está no formulário de criação e no modal Editar ligação, ao lado das acções de gravar:

1. Preenche os campos de ligação.
2. Carrega em Testar ligação. O botão passa a A testar….
3. A plataforma abre uma ligação verdadeira à base de dados, executa uma consulta inofensiva de verificação, e fecha a ligação. Nada é escrito nem alterado.
4. Sucesso mostra a confirmação "Ligação OK."; falha mostra um alerta com a mensagem devolvida pelo motor da base de dados — tal e qual, porque é ela que diz o que corrigir.

Dois casos particulares:

• A editar com a password em branco, o teste usa a password guardada — ou seja, testa a ligação como ela vai ficar depois de gravares.
• Num SQLite por criar não há botão — o ficheiro ainda não existe, e um teste ali só podia mentir. Aparece depois de gravar.

#O teste falhou — e agora?

A mensagem vem do motor, por isso varia; os padrões, não:

Sintoma	O que verificar
Demora e acaba em timeout	Host e Porto certos? O servidor aceita ligações da máquina onde a plataforma corre (firewall, rede)?
Erro de autenticação / login failed	Utilizador e Password. Nalguns motores, também se essa conta pode ligar-se a partir de outra máquina.
Base de dados desconhecida	O campo Database tem o nome exacto da base dentro do servidor.
Erros de SSL/TLS num SQL Server 2008/2012	Liga TLS legado (SQL Server antigo) — é exactamente para isto.
Erros de certificado noutros motores	Usar SSL / Encrypt conforme o servidor exige; em servidores internos com certificado próprio, Trust server certificate.
Oracle não encontra o serviço	A Connect string segue host:port/service_name? O service_name é o do serviço, não o SID?

#Credenciais que nunca voltam ao ecrã

A password de um datasource é de escrita única: entra no formulário, e a partir daí a plataforma não volta a mostrá-la — a ninguém, nunca, nem a quem a escreveu.

• Ao abrires Editar ligação, todos os campos vêm preenchidos excepto a password. O campo chama-se Password (vazio = manter): em branco, a actual continua; preenchido, substitui-a.
• Não existe nenhum ecrã, exportação ou permissão que devolva a password em claro. Se a perderes, redefine-a no servidor da base de dados e escreve a nova aqui.
• Em repouso, as credenciais ficam cifradas — como os próprios formulários dizem: "Tudo é cifrado em repouso."

#E quando a app viaja?

Ao exportares uma app (Definições → Exportar app), escolhes o destino dos segredos:

• Sem segredos (recomendado) — "As ligações dos datasources e os secrets seguem por preencher". Quem importar noutra instância volta a preencher as credenciais — as passwords não viajam.
• Com segredos, protegidos por passphrase — os valores seguem cifrados com uma passphrase que defines e que será pedida ao importar. "Sem a passphrase, os segredos do pacote são irrecuperáveis."

#Quem pode fazer o quê

Acção	Perfil necessário na app
Ver a lista de datasources e usar a app	Developer
Criar, editar, renomear, eliminar datasources	Administrador
Consola SQL, criar/alterar objectos (DDL)	Administrador

É por isto que um developer pode não ver o botão Adicionar datasource nem o menu Editar ligação — não é um erro, é o perfil.

#Tudo fica registado

• Histórico da app — cada criação, alteração, renomeação e eliminação de um datasource entra no histórico de alterações ("Datasource "crm" criado", "Datasource "crm" alterado", …), com autor e data.
• Auditoria da plataforma — as mesmas operações ficam na trilha de auditoria do Radar, com o alvo Datasource.
• Consola SQL — quando executas SQL que escreve ou altera (um UPDATE, um DROP…), o evento é auditado com o tipo de operação e uma impressão digital da query — sem o texto do SQL, para que dados sensíveis escritos na consola não acabem no registo.
• Radar → Estado — a secção Ligações a bases de dados mostra as ligações configuradas em todas as apps. E com uma cautela deliberada: "Esta página não liga a nenhuma delas sozinha: são bases de dados de produção, e abrir ligações a cada visita é tráfego que ninguém pediu."

#Boas práticas

• Conta dedicada, privilégios mínimos. Cria na base de dados um utilizador só para a app, com acesso apenas às tabelas necessárias. Tudo o que a app executa — APIs, scripts, consola — passa por essa conta.
• Aponta os testes a dados de teste. Ao testar uma API que escreve, a própria plataforma avisa: "O teste corre o pipeline a sério contra os datasources — uma mutation faz escritas verdadeiras. Confirma que estás a apontar a dados de teste."
• Cifra a ligação sempre que o servidor o permita (Usar SSL / Encrypt) — em especial quando a base de dados está noutra rede.
• Nomes que digam o ambiente. crm e crm-teste evitam o pior engano possível: escrever no sítio certo do ambiente errado.

#Perguntas frequentes

• O Keplin mostra-me a password que gravei? Não. É de escrita única — a alternativa é substituí-la.
• Testar ligação mexe nos dados? Não. Abre a ligação, corre uma consulta de verificação inofensiva e fecha.
• Porque é que o teste passa mas a query da API falha? O teste valida a ligação, não os privilégios sobre cada tabela. Se a conta não pode ler ou escrever numa tabela, é nessa query que o erro aparece.
• Mudei a password no servidor da base de dados — e agora? As APIs e scripts começam a falhar com erro de autenticação. Abre Editar ligação, escreve a password nova e Gravar.