Logins, Table Opens and Connection IDs
Disabling Automatic Login on Open Behavior
The DataFlex drivers have always supported an “automatic login on open” feature. The first time an Open statement is encountered for a particular server-string, it attempts an automatic login. If the login fails, a login dialog may be invoked. If that fails, the open is ignored and the program continues to run. This can be confusing for both the end-user and the developer. The login may occur at unpredictable times, and a program that keeps running after a failed login doesn’t run well. This often results in a cascade of errors. This behavior is inconsistent with the embedded database, where a failed open is considered fatal.
We now encourage developers to always log in to the server at the top of their application before opening any tables. If the login fails, you will know this at a controlled point, allowing you to handle the error more easily. When using the LoginAll method, a failed login simply closes the application; however, there are other choices. We further formalize this by creating a cConnection property named pbLoginOnOpen, which, when set to false, will not allow these auto-logins on open. If the server is not yet logged into, the open fails, and the program aborts. This makes everything much more predictable and controllable. However, this is optional, and you can use managed connections with the older auto-login on open behavior. By default, this property is true, maintaining legacy behavior. Consider setting this to false.
User Logins and Database Server Logins
An application has two types of logins: User and Database.
User Login
This is the login logic that you, the application developer, create to keep track of who is allowed into your application, what they are allowed to do, and how their activity is tracked. This is tracked by user and is generally what we think of as a “DataFlex login.” These are the logins that an application user typically sees. An example of a user login is the login dialog in the Web Application samples.
Database Login
This is the login required to log in to a database server. This is a lower-level login that is typically hidden from an end user. Often, this login is silent, and the login credentials needed for the login are provided by the application installer or database administrator. Multiple database logins may be needed within a single application. If you define multiple connection IDs, you will need to log in to each server.
The logins referred to in this document are all database logins. This is the login required to gain access to a database. Often, this occurs before the actual user login since a user login will require access to a user table, which must first be (database) logged into.
Therefore:
- Database logins occur at the application or workspace level.
- There is often a single database login for an entire application (i.e., all users of the application).
- These database login credentials are managed by the application administrator.
- These logins will normally be silent and therefore hidden from the end user.
- Database login credentials are stored in the
connections.ini, where they are shared by all users.
Credentials and Encryption
Login credentials (username, password, trusted connection) are stored in the connections.ini file. If you are using usernames and passwords (as opposed to trusted connections), you will want to encrypt your password in this file. The mechanism for encrypting needs to be private and known only to the application developer.
This creates some complications.
The biggest complication is that an encryption method known only to the application developer cannot be used by the Studio. This is solved by our tools maintaining and storing a separate encrypted password using our own private encryption mechanism.
The other complication is that the connections.ini text file becomes harder to manually edit when you need to enter encrypted data. We provide tools that make it easy to add a password and encrypt it.
The tool for encrypting and storing a database login password can be embedded inside your application. A dialog package named DatabaseLoginDialog.dg may be included in your application that behaves as follows:
- When a managed connection is logged into, a silent login is attempted. If this succeeds, the program continues.
- If the silent login fails, a database login dialog will pop up.
- If the explicit login succeeds, the login credentials are stored in the
connections.inifile, so the next time a login is needed, the credentials are correct.
This means that the database login dialog process only needs to occur one time. The tool required to store the login password is your application. The tool just happens to be embedded within your application, making it available when needed. If you don’t want to embed this tool within an application, you will need to create a separate tool to do this. Because your encryption logic is unique, this tool must be compiled by you. We provide a template for creating such a tool. This tool is basically a Windows program that invokes the login dialog and stores the result.
Studio Level Database Logins and Encryption
The application login and encryption strategy won’t work for the Studio and our tools. We don’t know what your application encryption strategy is (nor should we), so we do not know how to decrypt the stored password. This is solved by using a special “tools-only” password. This is encrypted/decrypted using a strategy known only by our tools. The developer does not know what our encryption strategy is (nor should they). This password is encrypted and stored in the connections.ini file with its own name (DFPWD instead of PWD). This is all maintained by the Studio.