Use the SQLSetConnectAttr() function to specify the callback function used by the server. SQLSetConnectAttr() is also used to specify what parameters are used by the callback function. Parameter attributes are passed back to the callback function exactly as they are specified to the driver.
The following attributes are IBM Informix-specific extensions to the ODBC standard:
| Parameter | Type | Description |
|---|---|---|
| SQL_INFX_ATTR_PAM_FUNCTION | void * | A pointer to the call back function. |
| SQL_INFX_ATTR_PAM_RESPONSE_BUF | void * | A generic pointer to a buffer containing the response to an authentication challenge. |
| SQL_INFX_ATTR_PAM_RESPONSE_LEN | int | The length of the response buffer in bytes. |
| SQL_INFX_ATTR_PAM_RESPONSE_LEN_PTR | int * | The address which stores the number of bytes in the response. |
| SQL_INFX_ATTR_PAM_CHALLENGE_BUF | void * | A generic pointer to a buffer containing the authentication challenge. The driver stores any challenge received from the server into this buffer. If the buffer is not large enough to contain the challenge, the challenge is truncated. The callback function can detect this by comparing the buffer length with the number of bytes in the challenge. It is up to the application developer to detect this situation and handle it correctly. |
| SQL_INFX_ATTR_PAM_CHALLENGE_BUF_LEN | int | The length of the challenge buffer in bytes. |
| SQL_INFX_ATTR_PAM_CHALLENGE_LEN_PTR | int * | The address which stores the number of bytes in the challenge. |
The challenge and response buffer pointers can be null. If the authentication server requires the information that would be stored in these buffers, a connection failure results due to an authentication failure. The challenge length information will be returned whether the connection is successful or not. If the message type does not require a response, the response buffer may be null (default) or it may contain an empty string.
The attributes above can be set at any time and in any order. However, they will only be valid for connections established with subsequent calls to one of the driver's connect functions.
An application programmer must be aware of the effects of connection pooling when using authentication. In ODBC, the driver manager controls connection pooling. The driver does not control when its connections are placed in the pool or when a connection is pulled from the pool. If the application connects and disconnects without the user's knowledge, the performance benefits of connection pooling will be maintained and the user will not receive any unexpected authentication challenges. If the application does make the user aware they are reestablishing a connection, there will still be no authentication challenge because the connection between the driver manager and the server was never closed. For more information on connection pooling refer to the Microsoft Data Access SDK documentation.
Any ODBC function which establishes a connection, SQLConnect(), SQLDriverConnect(), or SQLBrowseConnect(), can be used with authentication modules. Consider the following when using these functions:
The DriverCompletion parameter to the SQLConnect() function can take the following values
If an authentication challenge is expected, it is recommended that you use SQL_DRIVER_NOPROMPT. Using other values may result in the user being presented with multiple requests for authentication information.
SQLBrowseConnect() is designed to be used iteratively where the driver provides guidance to the application on how to complete the connection string and the application prompts the user for the required values. This can create situations where the user is presented with multiple prompts between connection string completion and authentication.
Additionally, it is typical for the driver to present a choice of databases to the application as part of the connection string completion process. However, the driver is not able to query the server for a list of databases until after the user is authenticated. Depending on application logic, whether or not it provides a database name in the original connection string, and whether or not a challenge is going to be received from the authentication server, it might not be possible to use SQLBrowseConnect() when the server uses authentication.
When using authentication, it is the responsibility of the application to handle any challenges that originate from the authentication server. To do this, the application programmer must be able to register a callback function with the driver. Because there are no attributes defined in the ODBC standard that are used to accomplish this, the attributes used are IBM Informix extensions.
Many applications are written using Microsoft's ADO layer to abstract the ODBC calls from the developer. Most Visual Basic applications are written using ADO objects. These applications and third party applications in general will not be aware of the IBM Informix extensions and will not be able to handle an authentication challenge.
The ODBC Data Source Administrator on Windows also falls under the class of third party applications. Not all features will be available when configuring a UNIX data source. For example, the Apply and Test Connection button and the User Server Database Locale toggle will not work if a challenge is received because those features require the ability to connect to the server.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]