Ligações

O catálogo de conectores

Cria ligações a partir da página Ligações do dashboard, limitadas ao teu ambiente.

Autenticação com referências secret://

As credenciais nunca vivem no dashboard em texto simples. Em vez de uma palavra-passe guardas uma referência secret://, e o agent resolve o valor real no momento da execução usando a sua própria identidade ambiente — nunca uma chave por ligação incorporada na configuração. Uma referência pode ser um campo inteiro ou estar embutida no meio de uma string:

secret://env/DB_PASSWORD
secret://aws-sm/prod/orders-db?key=password
secret://azure-kv/my-vault/orders-db
secret://gcp-sm/my-project/orders-db

• secret://env/NAME — uma variável de ambiente no host do agent (via a sua cadeia keyring → env).
• secret://aws-sm/… e secret://aws-ps/… — AWS Secrets Manager e SSM Parameter Store.
• secret://azure-kv/… — Azure Key Vault.
• secret://gcp-sm/… — GCP Secret Manager.

Exemplos práticos

Uma REST API. Cria uma ligação do tipo HTTP API, define o URL base (por ex. https://api.internal.example.com/v1) e escolhe a autenticação que a tua API usa — None para um endpoint aberto, ou um bearer token / uma API key guardados como uma referência secret://. Deixa Allow private networks desativado para um endpoint público; ativa-o para alcançar uma API na tua rede interna. As funções construídas por cima usam então caminhos relativos como /products ou /products/{'{{'}id{'}}'}.

Uma base de dados no host do agent. Cria uma ligação PostgreSQL a apontar para onde o agent alcança a base de dados — para uma base de dados a correr no mesmo host que o agent, isso é o host 127.0.0.1, a porta 5432, mais o nome da base de dados, o utilizador e a palavra-passe. Desativa Require SSL apenas se a base de dados não tiver TLS, e ativa Allow private networks para que o agent possa contactar um endereço privado/de loopback. A palavra-passe é guardada cifrada (ou como uma referência secret://) e só é resolvida no agent no momento da chamada.

Como é o agent — e não o backend — que contacta a ligação, o host que introduzes tem de ser resolúvel a partir da rede do agent, não a partir do ConnXL.

Ligar o Supabase

O Supabase aloja Postgres padrão, por isso o conector Supabase fala o protocolo Postgres diretamente com a base de dados do teu projeto. Duas coisas diferem de um Postgres auto-hospedado:

• Host e utilizador. Para uma ligação direta usa db.<project-ref>.supabase.co, porta 5432, utilizador postgres. Ao passar pelo pooler de ligações do Supabase, o utilizador passa a ser postgres.<project-ref> e a porta 6543 — o pooler é a escolha certa quando muitas réplicas do agent partilham um projeto.
• Modo SSL. O Supabase exige TLS mas a sua CA não está nos repositórios de confiança padrão, por isso o conector usa require por omissão (cifrado, certificado não verificado). Se instalares o certificado CA do Supabase no host do agent podes subir para verify-full.

A palavra-passe da base de dados está no teu painel do Supabase em Project Settings → Database; guarda-a como uma referência secret:// como qualquer outra credencial.

Para chegar ao mesmo projeto através da API REST do Supabase, com Row-Level Security aplicada por utilizador do Excel com sessão iniciada, vê Segurança ao nível da linha (troca de token).

Testar uma ligação

Usa Testar ligação no dashboard para verificar que uma fonte está alcançável. A sonda corre no agent, a partir de dentro da tua rede — um pedido HTTP, um SELECT 1 de SQL, ou uma varredura de cache. O backend nunca contacta as tuas fontes de dados por si próprio, por isso isto funciona para fontes que não são alcançáveis a partir da internet pública. As famílias de fonte sem uma sonda ao vivo reportam "guardado sem teste" em vez de falhar.

Podes gerir as ligações a partir da página Ligações do teu suplemento assim que um suplemento estiver selecionado.