Provare la connessione e la sicurezza

Un datasource conserva la chiave di un database vero — molto spesso, di produzione. Questa pagina copre i due lati di quella responsabilità: come confermare che la connessione funziona prima di salvare, e che cosa la piattaforma fa (e si rifiuta di fare) con le credenziali dopo.

#Provare la connessione

Il pulsante Prova connessione si trova nel modulo di creazione e nel modale Modifica connessione, accanto alle azioni di salvataggio:

1. Compila i campi di connessione.
2. Premi Prova connessione. Il pulsante diventa Test in corso….
3. La piattaforma apre una connessione vera al database, esegue una query di verifica innocua, e chiude la connessione. Non viene scritto né modificato nulla.
4. Il successo mostra la conferma "Connessione OK."; il fallimento mostra un avviso con il messaggio restituito dal motore del database — tale e quale, perché è lui a dire che cosa correggere.

Due casi particolari:

• In modifica con la password in bianco, il test usa la password salvata — cioè, prova la connessione così come resterà dopo il salvataggio.
• In uno SQLite ancora da creare non c'è il pulsante — il file non esiste ancora, e un test lì potrebbe solo mentire. Appare dopo il salvataggio.

#Il test è fallito — e adesso?

Il messaggio viene dal motore, perciò varia; gli schemi, no:

Sintomo	Che cosa verificare
Ci mette tanto e finisce in timeout	Host e Porta giusti? Il server accetta connessioni dalla macchina dove gira la piattaforma (firewall, rete)?
Errore di autenticazione / login failed	Utente e Password. In alcuni motori, anche se quell'account può collegarsi da un'altra macchina.
Database sconosciuto	Il campo Database ha il nome esatto del database dentro il server.
Errori SSL/TLS su un SQL Server 2008/2012	Attiva TLS legacy (SQL Server datato) — serve esattamente a questo.
Errori di certificato in altri motori	Usa SSL / Encrypt a seconda di ciò che il server richiede; nei server interni con certificato proprio, Trust server certificate.
Oracle non trova il servizio	La Connect string segue host:port/service_name? Il service_name è quello del servizio, non il SID?

#Credenziali che non tornano mai sullo schermo

La password di un datasource è a scrittura unica: entra nel modulo, e da lì in poi la piattaforma non la mostra più — a nessuno, mai, nemmeno a chi l'ha scritta.

• Aprendo Modifica connessione, tutti i campi arrivano compilati tranne la password. Il campo si chiama Password (vuoto = mantieni): in bianco, resta quella attuale; compilato, la sostituisce.
• Non esiste nessuna schermata, esportazione o permesso che restituisca la password in chiaro. Se la perdi, ridefiniscila nel server del database e scrivi la nuova qui.
• A riposo, le credenziali restano cifrate — come dicono i moduli stessi: "Tutto è cifrato a riposo."

#E quando l'app viaggia?

Esportando un'app (Impostazioni → Esporta app), scegli la destinazione dei segreti:

• Senza segreti (consigliato) — "Le connessioni dei datasource e i secret viaggiano vuoti". Chi importa in un'altra istanza ricompila le credenziali — le password non viaggiano.
• Con segreti, protetti da passphrase — i valori viaggiano cifrati con una passphrase che definisci e che verrà chiesta all'importazione. "Senza la passphrase, i segreti del pacchetto sono irrecuperabili."

#Chi può fare che cosa

Azione	Profilo necessario nell'app
Vedere l'elenco dei datasource e usare l'app	Developer
Creare, modificare, rinominare, eliminare datasource	Amministratore
Console SQL, creare/modificare oggetti (DDL)	Amministratore

È per questo che un developer può non vedere il pulsante Aggiungi datasource né il menu Modifica connessione — non è un errore, è il profilo.

#Tutto resta registrato

• Cronologia dell'app — ogni creazione, modifica, rinomina ed eliminazione di un datasource entra nella cronologia delle modifiche ("Datasource "crm" creato", "Datasource "crm" modificato", …), con autore e data.
• Audit della piattaforma — le stesse operazioni restano nella traccia di audit del Radar, con il bersaglio Datasource.
• Console SQL — quando esegui SQL che scrive o modifica (un UPDATE, un DROP…), l'evento viene registrato con il tipo di operazione e un'impronta digitale della query — senza il testo dell'SQL, perché dati sensibili scritti nella console non finiscano nel registro.
• Radar → Stato — la sezione Connessioni ai database mostra le connessioni configurate in tutte le app. E con una cautela deliberata: "Questa pagina non si connette a nessuna di esse da sola: sono database di produzione, e aprire connessioni a ogni visita è traffico che nessuno ha chiesto."

#Buone pratiche

• Account dedicato, privilegi minimi. Crea nel database un utente solo per l'app, con accesso alle sole tabelle necessarie. Tutto ciò che l'app esegue — API, script, console — passa da quell'account.
• Punta i test a dati di test. Provando un'API che scrive, la piattaforma stessa avvisa: "Il test esegue la pipeline davvero sui datasource — una mutation fa scritture reali. Assicurati di puntare a dati di test."
• Cifra la connessione ogni volta che il server lo permette (Usa SSL / Encrypt) — in particolare quando il database è in un'altra rete.
• Nomi che dicano l'ambiente. crm e crm-teste evitano il peggior equivoco possibile: scrivere nel posto giusto dell'ambiente sbagliato.

#Domande frequenti

• Keplin mi mostra la password che ho salvato? No. È a scrittura unica — l' alternativa è sostituirla.
• Prova connessione tocca i dati? No. Apre la connessione, esegue una query di verifica innocua e chiude.
• Perché il test passa ma la query dell'API fallisce? Il test valida la connessione, non i privilegi su ogni tabella. Se l'account non può leggere o scrivere in una tabella, è in quella query che l'errore appare.
• Ho cambiato la password nel server del database — e adesso? Le API e gli script cominciano a fallire con errore di autenticazione. Apri Modifica connessione, scrivi la password nuova e Salva.