Configuring Your Application

I l @ ve RuBoard

Before ASP.NET, moving an ASP application from a testing environment to a production server was typically the most difficult portion of a project's life cycle. An external DLL would need its own deployment package to handle the appropriate registry entries. The server would need to be restarted. Security settings and policies had to be manually configured. A simple oversight while setting up NT, IIS, ASP, or DCOM could have disastrous consequences for everything and everyone.

ASP.NET simplifies this process. Ultimately, the server administrator maintains all the control, but the developer can deliver a single package that will handle all of the system level configuration requirements for your application. This deployment package will contain everything that web server needs to run your application. It might include security settings for roles, policies, or even encryption methods . It can install and configure the appropriate DCOM and security settings for external DLLs. Nobody will have to restart the server or worry about how the installation might affect other applications running on the server.

When you release a new version of your application, you will deliver a similar package. The administrator will double-click your package and for a short time, the new and older versions of your application will run side-by-side. ASP.NET will direct new client sessions to the newer version of your application, and as soon as it recognizes that there are no longer any client sessions dependent on the older version, it will no longer be used. Once again, this process does not require the system or server to be restarted.

The file that you will use to configure most of system and application level settings for your application is called the WebConfig. The Web.config file is a simple XML file that allows you to configure system settings, security settings, application settings, and session settings for your application. We'll discuss it in greater detail in a bit.

As we discussed earlier, if all the application developers adhere to one common standard (XML), everyone's applications will be able to communicate and share services and data ”regardless of the actual programming language they were developed in. XML looks like a bunch of <HTML-ISH> tags, yet the tags only exist to describe and organize the data it contains. A parsed XML document looks like a tree of self-describing branches of data that contain self-describing data elements. It uses something called a "namespace" to make sure the client knows that the data within all the <titles> elements are referring to the <titles> of books, not the book authors' job <titles> elements. The only "presentation data" the XML file might include is a reference to some XSL. XSL is just an optional way to help transform the XML data into something more visually appealing.

XML is a strongly typed language, meaning that the code must be well formed with perfect syntax. In HTML, if you forget a closing </tag> here or there, the client's browser of choice will usually ignore your oversights and assemble the code the best it can. Breaking or bending XML coding standards, however, will always produce less than ideal results.

With a little well-formed XML and a web.config file, you've got all the power the server administrator never wanted you to have. In fact, she would be in a straightjacket right now if you asked her to configure half of the items .NET allows you to deploy and configure programmatically. It's kind of like your very own portable system administrator. On the other hand, you don't have to use it if you don't want to. If you feel comfortable with inheriting the systems' global settings, you don't need web.config at all. But if you want your application to terminate a session that has been inactive for more than five minutes (IIS's default is 20 minutes), a few simple lines of XML gives you all the power you need.

What Web.config Looks Like and Where to Find It

You can put a web.config file within an ASP application root directory or any of its subdirectories. Its mere presence is enough to override IIS's global settings with its own. Figure 10.2 shows the web.config file that we are using to authenticate clients for the application that accompanies this chapter.

Figure 10.2. Web.config is an XML-based configuration file that allows you to programmatically customize a variety of runtime settings for your application.

NOTE

Every web.config file needs to start with a <Configuration> tag and end with a </Configuration> to wrap the setting for your application.

Setting up Web.config

As you've probably noticed, the emphasis on consistent object-oriented programming (OOP) standards is a major part of .NET's initiative. There's really nowhere to run and hide from OOP these days, so if you're intimidated by it, get over it quick. You can make anything as complicated or simple as you choose to see it. Despite any overly complicated and abstract explanations you've heard in the past, the fact is, it's quite simple.

Establishing a reference to an object is a lot like putting a shortcut on your computer desktop. When you need quick access to a program on your hard drive, it makes more sense to place a tiny pointer on your desktop than it does to reinstall that application to your desktop. While you can give it a unique name to differentiate it from the other shortcuts on your desktop, it's still just a data store for the string variable that points to the real deal. Similarly, when you make a reference to an object in your code, the instance of that object is created with a pointer to its memory location.

Section Handlers

In order to configure a setting, you have to have a reference to the class object that manages those settings. For example, if you wanted to configure settings based on someone's browser capabilities, you need to make sure you include a reference to that class before you can manipulate the related settings.

You can add a reference to one of these classes, referred to as "configuration section handlers," by using code similar to the following:

  <Configsections> <add name ="objCoolBrowserCapReference" type="System.Web.HTTPBrowserCapabilities$SectionHandler" /> </Configsections> 

I know this object reference looks a little intimidating, but all it's really doing is turning the variable name you just added into a powerful class object a team of Microsoft developers wrote just for you. I know, I just upset a bunch of tightly wound OOP know-it- alls because the truth is that it didn't turn anything into anything! It's just like that shortcut we put on your desktop earlier. It's just an object variable that holds a pointer the compiled code. Nonetheless, the code above adds the appropriate reference so that you can configure browser capability settings.

<SessionState>

The <SessionState> handler gives your application control over five session state settings. Three of these settings are all related to storing sessions on a remote server, so they're grouped under the first bullet.

• Remote Session Storage ”By default, each session state is stored on the server. For applications that support a large number of clients, you might want to free up some system resources by storing each session state on a different server. In order to accomplish this feat, you'll need to change three state settings within the SessionStateModule$SectionHandler class:

  Set inproc="false" to indicate that you want the session in another server's process space. You'll also need to point to the server (for example, server="MyCoolStateServer" ) that will be storing the session data for your application. Finally, you should specify a remote port number by assigning the appropriate port number. port="YourPortNumber" setting.

• Cookieless ”Some clients don't like applications that use cookies. As we stated earlier, the Session ID is critical for us to be able to manage a client's session. Our only alternative is to encode a session ID into all of the URL strings a client can click. We can force ASP to do this for us by changing the cookieless property to "true". Its default setting is false to indicate that it should use a cookie to hold the session ID data. By the way, cookieless session management is much slower!

• TimeOut ”The last setting allows you to control how long a client is allowed to be inactive before we should terminate the session. You simply set the timeout property equal to the number of minutes (for example, timeout="13").

Deploying <Assemblies>

In the past, an ASP application was an organized collection of HTML pages with ASP code embedded within them. Deploying an ASP application required someone to manually duplicate the exact same environment that had existed on the machine it was tested on. This included the same directory structure and related files, IIS and security settings, and DNS entries for database access. If your ASP application made reference to an external DLL, you had to consider a deployment package for that executable, security privileges, and registry entries, as well as the impact these settings might have on other applications running on the same server.

In ASP.NET our applications are compiled into self-describing assemblies that function in many ways like self-extracting zip files. An assembly might include compiled code, the application's directory structure, system and application settings, versioning information, class libraries, and any external files or executable the code refers to. If your application requires an older 32-bit COM-based DLL, the file is added to the assembly like any other file, yet it will also include the appropriate registry and configuration data the server will need during the installation process. In other words, everything is automatically installed and configured to recreate the same environment that existed on the machine it was compiled on.

VS. Net's interface makes this process even easier, but you don't need VS.Net to achieve the same results. All VS.Net is doing is supplying you with user -friendly prompts that will handle the underlying details for you. The <assemblies> directive in the web.config file is used for adding and removing additional assemblies that will be passed to the compiler.

For example, let's say that you had just finished coding a .NET dll that replaces an older COM dll for one of your ASP.NET programs. Your trial version of VS.NET has just expired and you have ten minutes to build an updated version of your application. By making a few slight modifications to your code and the web.config file, you could essentially remove the old DLL and recompile it with the new one. Your web.config file might look like the following:

 <assemblies> <add assembly="YourNewDllComponent"/><remove assembly="YourOldDLLComponent" /> </assemblies> 

<WebServices>

Let's say that your friend's company in Alaska just finished building an application that retrieves real-time data about their wireless phone customers' phone usage. (For example, is their phone turned on? are they on a call? does their phone have the most recent flash upgrade installed?) Because your company handles service calls for them, he asks that you provide his customers an online interface that automatically upgrades their phone's software for them and guides them through the installation process. This will keep his customers happy, and will save everyone tons of time and money. Since his application is already set up as a Web Service (and was written in ASP.NET of course), you can retrieve the services he exposes to you and present the data in a browser.

The real techies might be curious whether I am implying that ASP.NET can handle events asynchronously. The answer is yes. What this means is that while your application is waiting for Event A to finish, it can handle other Events B, C, and D. In other words, you could incrementally update a control on a client's Web page that indicates the progress of their phone's installation. At the same time, the user could be updating their account data, which gets passed to your friend's database.

The following chapter will describe Web Services in much greater detail, but at this point just remember that you configure a variety of Web Service settings in web.config.

Authentication and Authorization in web.config

HTML Forms Authentication is a new feature for ASP and its settings are configured in the web.config file. It provides the developer a number of techniques to validate a client's credentials and control their access privileges accordingly . After we determine that a client is a valid user, we issue a cookie that stores their credentials in an encrypted key. Each time a validated client requests a new page, the key is passed in their HTTP Request headers so ASP will not have to revalidate their credentials.

<authentication>

There are four authentication mode settings your applications can use. You set the value of each authentication mode with the following syntax:

 <authentication mode="Cookie"> 

• None ”"None" means that your application doesn't have any authentication requirements. None means no, yes?

• Windows ”Also occasionally referred to as NT Authentication, it will validate a client's credentials based on its NT system's users and their permissions. NT creates an NT session ID that it uses to control the client's access based on its own security permissions.

• Cookie ”Although it's not the most secure approach to authentication, a client can pass a locally stored cookie to validate clients.

• Passport ”Microsoft has a pretty nifty new client authentication service called MS Passport Web Services, and it's free.

<cookie>

If you are using a cookie to validate clients, there are three cookie mode settings.

• cookie ” Your cookie needs a name. It's important to make sure each cookie has a unique name to avoid conflicts with other application's cookies. A cookie setting might look like:

   <cookie cookie="UniqueCookieName"> 

• DecryptionKey ” By default, your system will automatically generate a unique encryption key for its clients with the "autogenerate" setting. You can also provide your own key to encrypt the data, but this is really only necessary when your application spans a range of systems within a server farm. In other words, don't worry about it for now.

• loginurl ” When clients first hit application resources that require authentication, you can direct them to a specific page to validate their credentials. Your new and improved cookie code might look like this now:

   <cookie cookie="UniqueCookieName" loginurl="AuthenticationPage.aspx"/> 

We don't use cookies to authenticate users in our sample application, but if you peek inside this chapter's sample application, you'll notice an example of how to set and check for cookies in your own applications.

<credentials>

We also have the option to store people's user names and passwords within the web.config file. While storing credentials within the web.config is not an ideal approach for applications that need to validate the credentials of hundreds of clients, it's a perfect approach for smaller applications that only need to validate the credentials for a few clients. Larger applications will probably want to store credentials in a database.

There are three password format settings you can use to store the clients' credentials:

• Clear ”Usernames and passwords are not encrypted.

• SHA1 ”Passwords are encrypted and validated against the SHA1 algorithm.

• MD5 ”Passwords are encrypted and validated against the MD5 algorithm.

Both of the encryption algorithms require a reference to a special API that executes the algorithms. To keep things simple, here's some credential syntax for "clear" credential storage:

 <Credentials PasswordFormat="Clear"/> 

<user>

Storing client usernames and passwords for authenticating client credentials is easy.

 <user name="GlennC" password="human"/> 

<authorization>

Even if our user has valid credentials we need to either "allow" or "deny" them access to our application. If we want to allow Frank and Bobby access, but deny Glenn, our syntax might look like:

 <allow users="FrankZ", "BobbyB"/> <deny users="GlennC"/> 

If we wanted to assign access privileges to anonymous users, we could either "deny" or "allow" their access with one of the following:

 <allow users="*"/> <deny users="*"/> 

I should also note that there is a "roles" property setting you can assign when allowing or denying user access. You can customize user access privileges even further by assigning this property value to the name of role on the system. For example, if I want Frank and Bob to have Administrator privileges, I would modify their code to look like:

 <allow users="FrankZ", "BobbyB" roles="Administrator"/> 

I l @ ve RuBoard