Testa anslutningen och säkerhet

En datakälla förvarar nyckeln till en riktig databas — ofta en i produktion. Den här sidan täcker båda sidorna av det ansvaret: hur du bekräftar att anslutningen fungerar innan du sparar, och vad plattformen gör (och vägrar göra) med autentiseringsuppgifterna efteråt.

#Testa anslutningen

Knappen Testa anslutningen finns i skapandeformuläret och i modalen Redigera anslutningen, bredvid sparåtgärderna:

1. Fyll i anslutningsfälten.
2. Tryck på Testa anslutningen. Knappen övergår till Testar….
3. Plattformen öppnar en riktig anslutning till databasen, kör en harmlös kontrollfråga och stänger anslutningen. Ingenting skrivs eller ändras.
4. Vid framgång visas bekräftelsen ”Anslutningen fungerar.”; vid fel visas en varning med meddelandet som databasmotorn returnerade — ordagrant, eftersom det är det som säger vad som ska rättas.

Två specialfall:

• Vid redigering med blankt lösenord använder testet det sparade lösenordet — det vill säga, det testar anslutningen som den kommer att bli när du sparar.
• I en SQLite som ännu inte skapats finns ingen knapp — filen finns inte än, och ett test där skulle bara kunna ljuga. Den dyker upp efter att du sparat.

#Testet misslyckades — vad nu?

Meddelandet kommer från motorn, och varierar därför; mönstren gör det inte:

Symptom	Vad du ska kontrollera
Det tar tid och slutar i timeout	Är Host och Port rätt? Accepterar servern anslutningar från maskinen där plattformen körs (brandvägg, nätverk)?
Autentiseringsfel / login failed	Användare och Lösenord. I vissa motorer också om det kontot får ansluta från en annan maskin.
Okänd databas	Har fältet Database databasens exakta namn inuti servern?
SSL/TLS-fel på en SQL Server 2008/2012	Slå på Äldre TLS (gammal SQL Server) — det är precis vad den är till för.
Certifikatfel i andra motorer	Använd SSL / Encrypt beroende på vad servern kräver; på interna servrar med eget certifikat, Trust server certificate.
Oracle hittar inte tjänsten	Följer Connect string formatet host:port/service_name? Är service_name tjänstens namn, och inte SID:et?

#Autentiseringsuppgifter som aldrig kommer tillbaka till skärmen

En datakällas lösenord är skriv-en-gång: det går in i formuläret, och därefter visar plattformen det aldrig igen — för ingen, aldrig, inte ens för den som skrev det.

• När du öppnar Redigera anslutningen kommer alla fält ifyllda utom lösenordet. Fältet heter Lösenord (tomt = behåll): blankt behålls det nuvarande; ifyllt ersätter det.
• Det finns ingen skärm, export eller behörighet som lämnar tillbaka lösenordet i klartext. Om du tappar bort det: sätt ett nytt på databasservern och skriv in det nya här.
• I vila ligger autentiseringsuppgifterna krypterade — precis som formulären själva säger: ”Allt krypteras i vila.”

#Och när appen reser?

När du exporterar en app (Inställningar → Exportera appen) väljer du vad som händer med hemligheterna:

• Utan hemligheter (rekommenderas) — ”Datakällornas anslutningar och secrets följer med tomma”. Den som importerar i en annan instans fyller i autentiseringsuppgifterna på nytt — lösenorden reser inte.
• Med hemligheter, skyddade av en lösenfras — värdena följer med krypterade med en lösenfras som du anger och som efterfrågas vid importen. ”Utan lösenfrasen går paketets hemligheter inte att återfå.”

#Vem får göra vad

Åtgärd	Profil som krävs i appen
Se listan över datakällor och använda appen	Developer
Skapa, redigera, byta namn på och ta bort datakällor	Administratör
SQL-konsolen, skapa/ändra objekt (DDL)	Administratör

Det är därför en developer kanske inte ser knappen Lägg till datakälla eller menyn Redigera anslutningen — det är inte ett fel, det är profilen.

#Allt registreras

• Appens historik — varje skapande, ändring, namnbyte och borttagning av en datakälla hamnar i ändringshistoriken (”Datakällan "crm" skapad”, ”Datakällan "crm" ändrad”, …), med upphovsperson och datum.
• Plattformens granskning — samma operationer hamnar i Radars granskningsspår, med målet Datakälla.
• SQL-konsolen — när du kör SQL som skriver eller ändrar (ett UPDATE, ett DROP…) granskningsloggas händelsen med operationstypen och ett fingeravtryck av frågan — utan SQL-texten, så att känsliga data som skrivits i konsolen inte hamnar i loggen.
• Radar → Tillstånd — avsnittet Databasanslutningar visar de anslutningar som är konfigurerade i alla appar. Och med en avsiktlig försiktighet: ”Den här sidan ansluter aldrig till någon av dem på egen hand: det är produktionsdatabaser, och att öppna anslutningar vid varje besök är trafik som ingen har bett om.”

#God praxis

• Dedikerat konto, minsta möjliga behörigheter. Skapa en användare i databasen som bara är till för appen, med åtkomst enbart till de tabeller som behövs. Allt appen kör — API:er, skript, konsolen — går genom det kontot.
• Rikta testerna mot testdata. När du testar ett API som skriver varnar plattformen själv: ”Testet kör pipelinen på riktigt mot datakällorna — en mutation gör verkliga skrivningar. Kontrollera att du pekar på testdata.”
• Kryptera anslutningen varje gång servern tillåter det (Använd SSL / Encrypt) — i synnerhet när databasen ligger i ett annat nätverk.
• Namn som avslöjar miljön. crm och crm-test undviker det värsta tänkbara misstaget: att skriva på rätt ställe i fel miljö.

#Vanliga frågor

• Visar Keplin lösenordet jag sparade? Nej. Det är skriv-en-gång — alternativet är att ersätta det.
• Rör Testa anslutningen några data? Nej. Den öppnar anslutningen, kör en harmlös kontrollfråga och stänger.
• Varför går testet igenom men API:ets fråga misslyckas? Testet validerar anslutningen, inte behörigheterna på varje tabell. Om kontot inte får läsa eller skriva i en tabell är det i den frågan felet dyker upp.
• Jag bytte lösenord på databasservern — vad nu? API:erna och skripten börjar fallera med autentiseringsfel. Öppna Redigera anslutningen, skriv det nya lösenordet och Spara.