Security is a central aspect of maintaining a Web server computer and creating Web applications. Security experts recommend that you think about security at the beginning of your projects and that you make security an integral part of your Web application design. I hope that the information that I’ve presented throughout the book and in this appendix has helped you understand and anticipate the security issues that you’ll face as you create ASP.NET Web pages.
Throughout this book, I’ve been
To make your Web applications available to others, however, you need to publish, or deploy , the applications. As I explained in Chapter 3, you can either host a Web site on your computer, or you can copy your Web pages to a hosting site. Either way, you need to take specific steps to make your Web pages available to others. In this appendix, I’ll explain what you need to host your pages on a local Web site and how to copy pages and data to a hosting site. I’ll begin by discussing a locally hosted Web site.
If you’re using your own computer to host a Web site, you can use the Web pages you created in this book unchanged. However, you need to configure Internet Information Services (IIS) so that it can find your pages. You also need to make sure that your Web application can access MSDE or SQL Server properly.
Remember that if you’re using your computer to host a Web site, you must take appropriate security
When you use your computer to host a Web site, you must use IIS as your Web server. The Web Matrix Web server that you’ve probably been using won’t accept Web page
Don’t forget to configure your firewall to accept requests on port 80. Refer to the documentation for your firewall for instructions on how to configure it.
If you copy all your files to a subdirectory under C:\inetpub\wwwroot, you’ll need to edit the files in that subdirectory when you want to make changes. In other words, you won’t maintain files in C:\WebMatrix any more. If you create a virtual root in IIS, on the other hand, you can continue to edit files in the C:\WebMatrix folder, because IIS will read the pages from that folder. The choice is up to you. If you’ll be working with other IIS applications, you might find it
If you want to keep your Web pages under the Web server root folder, use Windows Explorer to create a folder under C:\inetpub\wwwroot. You can name the folder anything you like—that is, you don’t need to
If you want to leave your pages in C:\WebMatrix and create a virtual root, you can do so in two ways. The easy way is to have Web Matrix create the virtual root for you. Close Web Matrix if it’s open, and then reopen it.
Figure B-1: Creating an IIS virtual root using the Start Web Application dialog box.
When you click the Start button, Web Matrix creates an IIS virtual root with the name you specify. Alternatively, you can manually create a virtual root using the IIS management tools.
Create a virtual root using IIS tools
In the Windows Control Panel, open Administrative Tools and then open Internet Information Services.
Open the node for your computer.
Right-click the Default Web Site node, choose New, and then choose Virtual Directory. IIS opens the Virtual Directory Creation Wizard.
Assign an application name (alias) to the virtual root, and then specify where IIS should look for your pages—probably in C:\WebMatrix.
Select Read and Run Scripts access permissions. For security reasons, don’t select any additional access permissions.
Click Finish to create the new virtual root.
No matter which way you’ve created the virtual root, test it after you’ve finished creating it. Open your browser and type a URL like the following: http://localhost/ virtualroot /Guestbook.aspx , where virtualroot is the name you’ve assigned to the virtual root. If the page appears, IIS has recognized the virtual root name.
When you connected to a database in Web Matrix (whether MSDE or SQL Server), you probably used Windows Authentication. When you ran Web pages, the pages connected to the database under your Windows account name. However, when pages run under IIS, they don’t run under your account name; instead, the pages run under the ASPNET account, as I explained in Appendix A. As a result, by default, when pages run under IIS, your pages have a problem: they can’t connect to the database because the MSDE or SQL Server isn’t configured to allow access to the ASPNET account.
The solution is to configure MSDE or SQL Server to allow access to the ASPNET account. If you’re working with SQL Server, you can use the SQL administrative tools to set permissions. Refer to the SQL Server Books Online that comes with SQL Server for information on setting
osql -E -S MSDEinstance -Q "sp_grantlogin ’ computer \ASPNET’ osql -E -S MSDEinstance -d WebMatrix -Q "sp_grantdbaccess ’ computer \ASPNET’ osql -E -S MSDEinstance -d WebMatrix -Q "sp_addrolemember ’db_owner’, ’ computer \ASP NET’"
You need to substitute appropriate values for MSDEinstance and computer . The value for MSDEinstance is the instance name of MSDE on your computer. The value of computer is your computer ID, which you can find by right-clicking My Computer on the desktop and looking at the Computer Name tab. The value of computer is your full computer name, not including any domain information. For example, if your computer is named family-1 and you connect to MSDE using the instance name localhost , the first osql command looks like this:
osql -E -S localhost -Q "sp_grantlogin ’family- 1 \ASPNET’"
Execute all three of the commands that I listed earlier, in order. The three commands allow the ASPNET user to log in to MSDE; give the ASPNET user access to the WebMatrix database you’ve been using; and grant
privileges to the ASPNET user for the WebMatrix database, meaning the user can perform