Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Ich möchte das Passwort und die Benutzer-ID vielleicht in einer separaten Datei im Dokumentenordner des Benutzers ablegen. Etwas wie das:
Anmeldedaten.jsl
{"fred","1234"}
Sie können es verschlüsseln, wenn Sie möchten, aber das ist ziemlich sinnlos, außer um Ihren Hund davon abzuhalten, es anzusehen ...
Verwenden Sie in der Anwendung
{username,password} = include("$documents/credentials.jsl");
... use the credentials ...
username = .; password = .; // clear the variables when done with them
Die Include-Funktion gibt das Ergebnis der letzten in der Datei ausgeführten Anweisung zurück, die die 2-Elemente-Liste erstellt hat.
Ich tue dies hauptsächlich, um sicherzustellen, dass ich nicht meine eigenen Anmeldeinformationen in ein Quellcodeverwaltungssystem einchecke. Da sich die Datei außerhalb des Projektverzeichnisses befindet, wird sie nicht versehentlich abgeholt. Ich verschlüssele es, in der Hoffnung, dass jemand, der meinen Computer hackt, kein JMP hat. Vielleicht möchten Sie dem Dateinamen ein paar Informationen hinzufügen ... die App, die es benötigt, den Dienst, für den die Anmeldeinformationen gelten.
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Ich denke, dass das Verschlüsseln der Datei besser ist, als diese Informationen als Klartext zu haben.
Was wäre die vollständige Antwort, einschließlich eines sehr einfachen Verschlüsselungs-/Entschlüsselungsschritts?
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Siehe meine Kommentare oben: Dies ist nicht sicher. Aber hier erfahren Sie, wie Sie einem Angreifer eine kleine Bremsschwelle in den Weg legen können.
Verschlüsseln Sie diese Datei mit der Funktion encrypt() und führen Sie dann die verschlüsselte Datei aus.
// Pre-encrypt this using edit->encrypt script. There
// is no need to use a run password, and no reason to
// make a complicated edit password. "a" is good enough.
//
// Caution: this is not secure. No password is needed to
// view this data, though JMP is required to decrypt it.
// If you need a decrypt password+prompt, you'll need to
// manually go through the GUI for encrypting scripts.
// https://community.jmp.com/t5/Discussions/How-to-handle-user-password-information-in-JSL-ODBC-connection/m-p/627942#M82631
encrypt = Function( {name, pass}, {x},
x = Expr( 1 + 1 ); // throw an error if not working
// https://community.jmp.com/t5/Discussions/How-to-check-if-the-running-script-is-encrypted/m-p/624766#M82350
If( Char( Name Expr( x ) ) == "1 + 1",
Throw( "the encrypt function needs to be encrypted to work correctly." )
);
// strings generally stay unencrypted. expressions
// that are not simple strings or numbers try to stay
// encrypted. The concatenation operator is enough to
// keep the expression's strings encrypted.
Char( Eval Expr( {Expr( name ) || "", Expr( pass ) || ""} ) ); // return value
);
Führen Sie dies dann aus, um zu sehen, wie es funktioniert
// use the encrypted encrypt function to make an encrypted list
name = "fred";
pass = "1234";
crypt = encrypt( name, pass );
If( length(crypt) < 500 + Length( pass ) + Length( name ),
Throw( "not encrypted. Did you execute the *encrypted* file containing the encrypt function?" )
);
file = Save Text File( "$temp/credentials.jsl", crypt );
name = .;
pass = .;
///////////////////////////////////////////////////
{name, pass} = Eval List( Parse( Load Text File( file ) ) );
write("\!nsaved file contains\!n",Load Text File( file ),"\!n\!ndecrypted is");
show(name,pass);
gespeicherte Datei enthält
{JSL Encrypted("//-e12.1\!r\!n0,\!r\!n208,4193eJwNytmBhSAMAMB+tgWCCRBUkMuLgP0X8na+B3NI2evLjsG330/RUttTTEpOYhEyJ7JlBa2j1uAnpks3G3wTgpF7tJ8jqYrL\!r\! nPvBetVXPxNjKIWh06B9i+P/zfrd+bo6IP7eUOA3kSsGoaGA1x0ovXovyGmy481u4wqIGYKnEhvuG6XAE4Qk19cmunKo32uGJkuTv\!r\!nB +khNtw=\!r\!n,0,"), JSL Encrypted("//-e12.1\!r\!n0,\!r\!n208,4193eJwNzIkBxBAQAMB+rgWE9R1hQ/z0X8jdFDAcfUTDilxLV+PeyWbK7YEYHKE3A1bfMa7gUzjO2CxkyPwsV DPxS0TN9WNptpRC\!r\ !nLxnShIpDYKmeKzWIoUTSF6XX/fjReuqKrYKwJ9yptTwR2DfaI2j/AlFVHd/bP3Mqa0cFcuV1KCuTGp9XmOmvrXe9+Dai8GNZN+Hz\!r\!nAxwZN40=\!r\!n,0,")}
entschlüsselt ist
name = "fred";
pass = "1234";
JMP enthält keine Funktion zum programmgesteuerten Verschlüsseln von Skripten, sondern nur die interaktive GUI. Diese Problemumgehung lässt die Angabe des Ausführungs- oder Bearbeitungskennworts nicht zu. Es gibt kein Ausführungskennwort (jeder kann es ausführen) und das Bearbeitungskennwort ist unbekannt. Sie könnten eine andere Lösung bevorzugen, die setzen würde {"fred","1234"} in einem Bearbeitungsfenster und lassen Sie den Benutzer vor dem Speichern manuell verschlüsseln (oder nicht). Der Benutzer könnte dann entscheiden, ob er nach einem Laufkennwort gefragt werden möchte, was etwas sicherer wäre.
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Unter Windows verwende ich gerne den Credential Manager:
Anmeldeinformationen im Credential Manager über PowerShell unter Windows festlegen und abrufen
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)In diesem Discovery Summit-Vortrag skizziere ich einen Ansatz, der verschlüsselte Anmeldeinformationen verwendet:
https://community.jmp.com/t5/Discovery-Summit-Americas-2022/JMP-and-Oracle-Tips-and-Tricks-for-a-Happy-Marriage-2022-US-30MP/ta-p/ 505583
Suchen Sie nach dem Abschnitt „Passwort verbergen“.
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Dies als eine der Datenbanken zu akzeptieren, war Oracle. Danke für die ausführliche Anleitung.
Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Ich stelle über ODBC eine Verbindung zu einer Datenbank her, für die zu diesem Zweck ein bestimmter Benutzer und ein Kennwort erstellt wurden (die Verwendung von Windows Active Directory oder anderen ist nicht möglich).
Beim Erstellen der Abfrage speichert das Tabellenskript die Benutzer-ID.
Es wird nach einem Passwort gefragt, es kann aber auch direkt in die Verbindungszeichenfolge in JSL codiert werden.
Was sind die besten Optionen, um mit solchen Situationen in JSL umzugehen?
JMP-Dateien können geteilt werden, Updates sollten jedoch bei der ersten Ausführung nach einem bestimmten Benutzer und Passwort fragen.
Automatisierung und SkripterstellungDatenzugriffBetreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Einen ähnlichen Ansatz habe ich in dieser Diskussion aus dem Jahr 2018 gefunden:
Datenbankverbindung mit Anmeldeaufforderung
Welchen Vorteil hat die Verschlüsselung des Codes für die Verbindung zur Datenbank?
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Wenn JSL-Code verfügbar ist, der zum Öffnen einer Datenbankverbindung ausgeführt werden kann, kann jeder Benutzer mit diesem Code (verschlüsselt oder nicht) auf die Datenbank zugreifen.
Daher ist es wichtig, eine festzulegen Kennwort ausführen um zu verhindern, dass Benutzer das Snipet ohne Erlaubnis verwenden?
Andererseits wird es mit dem Run-Passwort ziemlich unangenehm, den Code zu verwenden – und zwar automatisch.
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Ich würde sagen, geben Sie keinen solchen Code weiter, der nicht von jedem verwendet werden sollte (wenn Sie kein Laufkennwort festlegen möchten). Es kann auch hilfreich sein, bestimmte Benutzer zu erstellen (zumindest können Sie dann das Passwort einfacher ändern/diesen Benutzer deaktivieren) und die IT-Abteilung einzubeziehen, damit sie überprüfen kann, wer welche Abfragen womit durchführt und entsprechende Maßnahmen ergreifen kann.
Sie könnten höchstwahrscheinlich auch den Anmeldeinformations-Manager (unter Windows) verwenden, um diese Passwörter zu verwalten @ich h habe vorgeschlagen (damit Sie sie nicht in der JSL-Datei speichern müssen). Ich habe den Credential Manager (noch) nicht mit JMP verwendet, aber ich habe ihn beim Aufbau von RPA (Robotic Process Automation) verwendet und es hat gut funktioniert.
Betreff: Umgang mit Benutzerkennwortinformationen in JSL (ODBC-Verbindungszeichenfolgen)Dies ist einer der Gründe, warum ich den Windows-Anmeldeinformationsspeicher so gerne verwende: Das Passwort ist für andere Benutzer einfach nicht verfügbar.Das Speichern des Codes oder der Dateien mit diesen Anmeldeinformationen an einem Ort, auf den nur ausgewählte Personen Zugriff haben, könnte einen ähnlichen Effekt haben.
Re: How to handle user password information in JSL ( ODBC connection strings )How about this:
use Windows AD rights to control the database access:
- generate a script to access the database - including the access rights for the database
- encrypt the file in JMP such that no user can see the password in plain text
- inside the script, try to access a file on a network share with AD access rights
if a user is allowed to access the file, he can use the database access.
for a user without access rights, the script will just show the error message
queryDB = Function( {SQLString},
pwd = Load Text File( "network path with AD rights" );
If( pwd = "my secret password",
result = New SQL Query(
Connection( "ODBC:DSN=database;PWD=xxx" ),
QueryName( "new" ),
CustomSQL( SQLString )
),
Caption( "no access rights" )
)
)
