Using Connection Strings
Connection strings are versatile, and because they're dependent on a specific setting within your system, you can place them almost anywhere in an application. This capability can become a liability, however, because developers often make the mistake of embedding DSN-less connection information in every Web page, then discover that keeping that information up-to-date is a maintenance nightmare. When you work with DSN-less database connection information, each application should have only one repository for connection information. You can locate this repository in one include file, in the system registry, or—as Microsoft suggests—in a Microsoft .NET web.config file.
Putting the information in an include file that's part of the Web site is a good idea because the file moves with the content that's associated with the site. Therefore, if you move the content from one server to another server, the database settings automatically move, too. You might be concerned that embedding the username and password in an include file would expose the information to intruders. This approach does represent a risk, but several factors mitigate that risk. For example, you can encrypt the username and password, then boost performance by decrypting them and loading the clear versions into application memory when you use them. You can further mitigate the risk and secure the environment by limiting the privileges associated with the database accounts that the application uses.
The registry is an excellent central storage location for application settings because Active Server Pages (ASP) and components can easily access it. However, registry entries don't automatically move with Web files. Connection-string data stored in the registry probably won't be the only such settings on an ASP site. In ASP, as opposed to ASP.NET, several application settings related to component registration probably live in the registry. Although tools such as Microsoft Application Center 2000 can manage many Web server settings across all the servers in a Web farm, keeping settings in the registry doesn't give you all the benefits that connection strings can provide.
ASP.NET lets you package a Web application as a set of files by using the web.config file to include settings associated with a connection string. When the Web application starts, it loads these settings into memory and makes them available to the Web site's pages and components. For example, within the web.config file's XML code in an ASP.NET application, you'll find the SessionState node. Within the SessionState settings, Visual Studio .NET automatically generates a placeholder connection string. Using that connection string, you can quickly customize a Web-farmhosted application to automatically use a SQL Server Cluster so that session data is available to all the servers in the Web farm.
When I use ASP.NET as an example, I don't mean to imply that only ASP.NET-based applications let you place connection information in one location. You can achieve a similar result in other applications by placing the information in an include file or other file that IIS doesn't directly reference. You want to be able to update the connection information, and having that information in one location simplifies that task. During the application's lifetime, you'll need to update the connection string when you move or rename servers.
Furthermore, as with other account information, you'll want to maintain security by regularly changing the credentials that the application connection string uses. If you're working with application developers, be sure that they include in the application a way for an administrator to change the connection-string credentials. To manage this requirement, you need to include a change to the application connection credentials in your application test plan. The final development step should be to thoroughly test the application to ensure that all the application components (e.g., pages, DLLs, config files) are packaged correctly.
The developers will need to obtain the SQL Server account information and set the application's connection strings and environment settings before testing the application. After the application is set up in the testing environment and is connected to the SQL Server database, change the connection information to test that administrative function. Performing this test early in the testing phase will give the development team time to correct problems. If you make any exemptions to let testing continue until the software that uses embedded connection strings is corrected, you should again change the connection information as the final step in the testing cycle to ensure that the feature still works. When preparing to move an application to a test or staging environment, developers ask for the SQL Server account information so that they can set the application's connection strings and the application environment settings. After the initial application setup and after you demonstrate connectivity, you can make changes to the connection information. These changes can be the first step in your test plan. If the application is written to use connection information that's stored in one location, this test should be simple to perform. Conducting this step early in the test plan will give the development team time to correct problems, but remember that if you make any exemptions, this test should also be the final test for the application. As an administrator, you don't want to be in a situation in which you can't maintain the accounts associated with database access because the connection string is scattered throughout various files and registry keys on your server.
Preparing to Manage an Enterprise Application
Unlike a desktop environment, which almost guarantees single-user access and control over the local file system, the Web is a multithreaded, multiuser environment—in some cases, it's even a multiserver environment. A robust database solution such as SQL Server is an important component of a scalable, multithreaded environment that supports multiple users simultaneously. Applications that use easily modifiable DSN-less connection strings to manage access to the database keep the connection details separate from the OS details. As I'll discuss in a future article, by properly managing the acounts associated with application data access, you can create a secure environment for your public-facing Web applications.
End of Article
Prev. page
1
[2]
next page -->
