Microsoft Office 2000/Visual Basic Programmer's
Guide |
|
Controlling the Level of Access
The strategies for controlling the level of access once a database is opened from a data access page are similar to those used in desktop solutions. For Access databases, you can use either of the following methods after establishing User-Level security for the database:
-
Define a user account that has the appropriate level of access you want to allow for any user of the data access page. Use the Data Link Properties dialog box to save this account name and password in the data access page connection information. This account and password will be used for all users who open the data access page. Also be sure to put the correct workgroup information file in a shared location and specify the path to the file in the Data Link Properties dialog box, as described in "Preventing Unauthorized Access" earlier in this chapter.
-
Define the appropriate groups and access levels you want to allow for users of the data access page. Create user account names and passwords to distribute to authorized users of the data access page, and assign those users to the appropriate groups. Use the Data Link Properties dialog box to prevent the password from being saved in the data access page connection information, as described in "Preventing Unauthorized Access" earlier in this chapter. Be sure to specify the correct workgroup information file in the Data Link Properties dialog box. All users of the data access page will be required to enter a valid user name and password before the database can be opened.
For SQL Server databases, the methods you can use are similar to those used with Access databases; in addition, you have the option of using Windows NT authentication:
-
Define a native SQL Server user account that has the appropriate level of access you want to allow for any user of the data access page. Use the Data Link Properties dialog box to save this account name and password in the data access page's connection information. This account and password will be used for all users who open the data access page. In SQL Server databases that use native security accounts, user and group account information is stored on the server itself, so you don't need to specify a workgroup information file as you do when connecting to a secured Access database.
-
Define the appropriate groups and access levels you want to allow for users of the data access page. Either create native SQL Server user account names and passwords to distribute to authorized users of the data access page, or use Windows NT integrated security. Assign users to the appropriate groups. If you use native SQL Server accounts, use the Data Link Properties dialog box to prevent the password from being saved in the data access page's connection information so that users of the data access page will be required to enter a valid user name and password before they can open the database. If you use Windows NT integrated security, use the Data Link Properties dialog box to specify that the data access page use that method to authenticate users who can open the database the page is connected to.
When you use both Access databases and SQL Server databases with data access pages, if you want to allow users to update information in the database, you must grant the appropriate permissions (such as Update, Insert, and/or Delete permissions) on the tables that contain the data you want to update. Granting permissions on a query (Access) or view (SQL Server) used by the data access page is not sufficient.
Important Depending on the data access method you choose for the data access page, where the database is located on the network relative to the IIS server used to publish the page, and how authentication is defined on the IIS server, you may not be able to control the level of access for individual users. That is, you may only be able to control access based on a single account used for all users who open the page. For more information, see "Configuring Authentication Methods Used on Internet Information Server" later in this chapter.