How Remote Database Security Works
The StoreFront Database Connection dialog box appears every time you use one of the StoreFront client tools in FrontPage. From this dialog box, you manage the connection between the StoreFront tools and the database.
Before the Web store is published, the Web author uses the local Access database file storefront.mdb, which he or she will set to the local DSN on the local server. When the site is published to the production server and has gone live, the Web author and store administrator use the Remote Database Connection feature to access the DSN on the production server through the StoreFront tools. In this way, they can administer the site and maintain the product database.
When an author logs on to the database remotely, the MDAC handles the connection to the database after that author has provided satisfactory security credentials to IIS. If the author is using FrontPage and has already provided credentials to open the Web site, FrontPage automatically supplies those credentials to IIS. This FrontPage feature is a nice time-saver, but it leaves you with the impression that the database isn't secure.
To test the security of your MDAC virtual directory, open the remote FrontPage client and click StoreFront Administration (don't open the Web site). The StoreFront Database Connection dialog box will appear. Make sure the Use Remote Database Connection check box is selected, then enter the Host and DSN you want to test. Click OK. If you didn't enter your username and password in this dialog box, the system will prompt you for them. Now you know that the database is secured against remote access by unauthorized users.
Test, Test, Test
Before your store goes live, I encourage you to test it thoroughly. Here's a checklist to help you cover all the bases:
- Make sure the store is running correctly in the new environment.
- Verify that the Web author has generated the product pages correctly.
- Verify that the search page and search results pages are functioning.
- Make sure the order cart and fulfillment sections let you place an order.
- Verify that the email order and confirmation are being sent.
- Test the reports; verify that all your test orders are present and accounted for.
- Make sure all the reports generate and print.
When you're satisfied that the store is functioning properly, test your Secure Sockets Layer (SSL) connections for store administration. If you're performing a quick installation that doesn't send information through a payment processor, you need to set up only SSL and a certificate to receive the transactions and secure the store administration. (See Brett Hill, IIS Informant, June 2000, for a tutorial about setting up a certificate.)
Finally, test the store's connection to the payment-processing company (if it has one). A discussion of payment processor installation is beyond the scope of this article. Each payment processor is different and requires different installation, authentication, licensing, and so on. Test primarily to make sure you've correctly installed and configured the payment-processing service on the server.
Take Care of the Database
When the store is running, the production database becomes the main database because it contains all the store's products and customer records. You certainly don't want anyone to overwrite this database by accidentally publishing the fledgling StoreFront database from the development machine over it. Best practice is to back up the entire Web store site to a functioning shadow Web site before anyone publishes Web pages or updates the database. Be prepared to fall back to your backup quickly if it's necessary. If you can't coordinate this approach, then perform backups as often as possible.
In addition, when the store is live, the store administrator (this administrator can be the Web author or an employee of the store owner) can make changes to the product database, orders, reports, and customers through the StoreFront Tools in the FrontPage client. The administrator can also use the HTML-based store administration tools that are installed in the \admin directory of the Web store when you install StoreFront.
To test new pages and page updates after the store goes live, the Web author must either set up a remote connection from his or her workstation to the production database or make a physical copy of the database to the workstation. I don't recommend the second option because it creates change-management problems; also, it's feasible only with Access, not with SQL Server.
Tip: StoreFront installation doesn't always install crpaig32.dll, a Crystal Reports DLL necessary for report generation. You can find the file in the StoreFront_temp_ directory and copy it to C:\winnt\system32. An FAQ on this DLL is at http://www.storefront.net/software/support/kbase.asp.
Tip: In Step 9, make sure the StoreFront database DSN has a different name from the DSN the Web author used on the development machine (e.g., tackshackprod, contrasted with the Web author's DSN tackshackdev). This distinction will save a lot of confusion when the store goes live and the author needs to be sure that he or she is working with the production database.
Tip: You must perform Step 3 on the personal Web server running on the Web author's workstation. Otherwise, the server won't process the ASP pages.
End of Article
Prev. page
1
[2]
next page -->
