查看完整版本: Databases　in　Dream　weaver　MX

Databases　in　Dream　weaver　MX

Databases in Dream weaver MX

Macromedia Dream weaver MX is an exciting release because it brings the ability to create dynamic web applications to a large audience. More people than ever before now have the tools they need to quickly and easily connect their web sites to databases and do everything from collect e-mail address to open fully functional storefronts. With that power comes quite a bit of responsibility, however-both to yourself, your clients, and the users of your site. You have a responsibility to create a secure application, which for our purposes means protecting the data that you collect and store so that it doesn't fall into unauthorized hands. Creating a secure application is not an especially difficult task, but it does mean paying some attention to what you are doing. Some steps that you can take during the development and deployment of your site will go a long way toward protecting your data. They involve not only Dream weaver MX itself but the database program that you use.
   Indexed Sequential Access Method (ISAM) databases include the popular file-based databases like Microsoft Access, FileMaker, and FoxPro. They are typically self-contained and can be accessed through a driver； they don't need a server application to run them. They are often created locally and then uploaded to a web server when a connection is made through a Data Source Name (DSN), a hard-coded connection path (DSN less connection), or a server-specific method like Server. MapPath in ASP. ISAM databases are inexpensive and easy to use. They are also easy to compromise if you don't follow a few simple steps to protect them. First, take care where you store the database file. If at all possible, store the database file in a folder that is above the root of your website on the server. For instance, if the physical path to your website on the web server is c:\websites\mywebsite, then the root folder my website and all the folders underneath it are accessible from a browser. This means that if you store your database file in the folder c:\websites\mywebsite\database, someone who knew or guessed the name of your file could download it from your site by simply browsing to [url]www.mywebsite.com/database/filename.mdb.[/url] Because the server would have no associated program with which to run an MDB file, it would allow the user to download the file. Second, you can avoid the possibility of a user downloading your database by performing a simple operation that takes advantage of a bug in Windows NT and Windows 2000 Server. Encrypt the database in Access and rename its extension from .mdb to .asp. Then, use the .asp filename in a DSN-less connection. Because the database is encrypted and named with the .asp extension, the ASP server will try to process it as ASP-and will fail and throw an ASP tag error if a user tries to download the file. Finally, assign your database a username and password. Microsoft Access, for instance, comes with the default username, Admin. Until a password is assigned for the Admin user, none is required. So whenever the database file is accessed, the program assumes that it is to log in the Admin user with a blank password. If someone is able to find and download your database file, there will be nothing stopping that person from opening it and examining your data. Securing database servers Database servers are full-featured data store applications like Microsoft SQL Server and Oracle. (I won't get into middle-ground applications like MySQL but some of the same concepts apply.) There are three things you need to take into consideration when securing applications that run on databases that are accessible to the Internet: physical security, virtual security, and internal security.