Course ASP : Troubleshooting Tips and Techniques

Course ASP :  Troubleshooting Tips and Techniques

Where and When is the Problem Occurring?

When you use Active Server Pages (ASP), you’re operating in the client/server world of Microsoft® Internet Information Server (IIS) and the HyperText Transfer Protocol (HTTP). Many customers who don’t have a firm grasp of this architecture find themselves puzzled by strange errors in what seems to be straightforward code. If you’ve ever been in this situation, don’t fret. The world of ASP and HTTP can be confusing, especially when you’re new to the technology.

Let’s take a look at the sequence of events that occur when a client, such as Internet Explorer, requests an ASP page. This discussion does not take into account the complexities of authentication on the ASP page. In our simplified discussion, the following three events take place:

1.   The client (Internet Explorer) requests an ASP page by sending an HTTP Request message to the Server.

2.   The server (IIS) recognizes that the requested page is an ASP page because it has an .asp file extension, and sends the asp file to asp.dll for processing. This processing includes execution of all server-side scripting code. (This step does not occur when the client requests an .htm file.)

3.   The server sends the resulting HTML page back to the client in the form of an HTTP Response.

Once the client receives the response, it executes any client-side script code and displays the Web page according to the HTML specification. While this process looks simple, keep in mind that the client and server could be hundreds, or even thousands, of miles apart. Therefore, when a problem arises, you must determine where the error is occurring: on the client or on the server? Equally important is understanding when each operation takes place. After ASP completes its processing in Step 2 and sends the response in Step 3, it moves on to other activities and other clients. The only way the client can recapture the server’s attention is to request another page via the HTTP protocol. In other words, there is no real connection between the client and server. This is a very important concept that must be understood. In the following paragraphs, I describe common types of problems encountered by ASP developers, and demonstrate the extra effort that is often required to promote communication between the client and server.

One type of problem occurs when developers try to access server-side scripts or objects from the client, or conversely, client-side objects from the server. As an example of the first scenario, consider client-side code that attempts to access one of ASP’s Intrinsics, such as the Session object. This is destined for failure because the code running in Internet Explorer has no way of accessing the object located on the server. A typical error message might appear as follows:

VBS Script Error: Object Required: Session

Now consider the second scenario, where a server-side script attempts to manipulate a client-side object. For example, suppose you use server-side scripting to populate a client-side ActiveX™ Listbox Control. While this seems like a simple task, you must keep in mind that the HTML page, and therefore the list box, does not yet exist when the server-side code is executed. Because the list box control hasn’t been created when the server-side script is run, the following code,

<% ListBox1.AddItem Value1 %>

will generate a similar “Object Required” scripting error. To accomplish this task, use server-side code to generate client-side code that will populate the list box. You should put this code in the Window_OnLoad event, where it is guaranteed to be executed by the browser after the window and its child controls are created. The following code segment demonstrates this technique. The server-side scripting code substitutes the values stored in variables Value1, Value2, and Value3, into the AddItem method calls.

Note that if you use the HTML tag instead of an ActiveX control, the procedure is slightly more direct. Because a list box created with the tag is based on HTML code, you can use server-side scripting to create the tags. The following example fills an tag with data provided by a field in the current record from the RecordSet, rs. Since there is no object creation, you do not need to place this code inside the Window_OnLoad event.

"> <%= rs("Name")%>

Another common problem encountered by ASP developers involves passing client data to the server. Consider the following scenario: Suppose you want users to log on to your Web application by providing his or her name and ID number. To accomplish this task, you create a simple HTML page with two INPUT items in an HTML form. The user is expected to enter the name and ID and press Submit. After the user submits the requested information, ASP verifies the user’s credentials through a database query. If the information is correct, you allow access; otherwise, this user is denied access to the page. The subtle point often overlooked in this procedure is passing the information provided by the user to ASP. Recall that the only way the client can recapture the server’s attention is to request another page via the HTTP protocol. In this case, the best approach is to POST the HTML form to an ASP page. Posting the form generates an HTTP Request that invokes ASP to process the requested page. During this ASP processing, the server-side script retrieves the posted data by calling Request.Form, and performs the database query and other verification logic. The following code demonstrates a simplified version of this procedure. Notice that the user information is actually posted back to the same ASP file that displays the form. This is perfectly valid, and is often more convenient than posting to a second ASP page.

<%@ LANGUAGE="VBSCRIPT" %>

<% IF IsEmpty(Request.Form("Name")) THEN

    Response.Write "Please enter your Name"

%>

   

     

    TYPE=TEXTBOX MAXLENGTH=20>

  

   

<%

   ELSE 

      'User verification code goes here

      Response.Write "Welcome " & Request.Form("Name") & "!"

   END IF

%>

If you need to pass information from ActiveX controls on the page to the server, you will need to add client-side scripting that reads the values from the controls and stores them in members of a “hidden” form, which is posted to the ASP file. Another variation of this technique is to pass the values to ASP using the query string, although this approach is limited by the length restrictions imposed on the query string by the HTTP specifications for the GET request.

As demonstrated in the preceding examples, ASP development requires a bit of creativity at times. However, keep in mind that many of these hurdles are actually imposed on ASP by the HTTP protocol and the client/server nature of Web development. If you consider some of the alternatives, I think you’ll agree that ASP is well worth the effort.

Who is Having the Problem?

By far, the largest segment of ASP issues handled in Developer Support involves security and permission problems. In order to avoid these problems, ASP developers must have a firm grasp of IIS authentication and controlling access to pages using NTFS file permissions. Although a thorough discussion of these topics is beyond the scope of this article, I will touch on the basic concepts and highlight the typical problems ASP developers encounter. For more information about securing your ASP application, see Securing Your ASP Application in the Scripting Guide included in the ASP online documentation (Roadmap).

Let’s begin with a quick overview of the client authentication types. Internet Information Server 3.0 supports three authentication schemes: Anonymous, Basic (Clear Text), and Windows NT® Challenge/Response. Each of these authentication methods is enabled or disabled through the WWW Service Properties page in Microsoft Internet Service Manager. A typical IIS configuration has Anonymous enabled, as well as either, or both, of the other methods. Anonymous authentication is the least secure method, while Basic and Windows NT Challenge/Response provide differing levels of security for your Web pages. The advantage of Basic authentication is that it is part of the HTTP specification, and is thus supported by most browsers

. The disadvantage of Basic authentication is that if someone is monitoring packets on your network, they could easily intercept and decipher your password using publicly available algorithms. This is not possible with Windows NT Challenge/Response authentication because the actual password is never sent over the wire. Instead, the browser returns a custom token that satisfies the server’s authentication request.

Although NT Challenge/Response is very secure, it does have a couple of limitations. The first limitation is that only Microsoft browsers support this proprietary scheme. Another limitation is that Windows NT Challenge/Response does not work over HTTP Proxy connections.  Because of these limitations, Windows NT Challenge/Response may not always be the best choice for an Internet server, however it is often ideal for intranet use. As you can see, choosing an authentication method is a trade-off in security verses flexibility.

Now let’s discuss the authentication process. Before IIS returns a requested page to a client, it first verifies that the client has permission to view the page. 

Although you can restrict permission to a page by turning off Read and Execute permissions on its virtual root in IIS, we will assume that both Read and Execute permissions are granted in IIS for the virtual root. The preferred method of restricting access to individual pages is to use NTFS file permissions to control which users can view the page. Before returning a page to the client, IIS checks the NTFS file permissions on the page to see if the current user is allowed access to the file. In order to know who the current user is, you must understand the authentication process used by IIS. 

When you configure IIS for Anonymous authentication, you must provide a username and password for the Anonymous Logon account. By default, this account is set to a user called IUSR_MACHINE, where MACHINE is the machine name of the Web server. IIS attempts to authenticate the Anonymous Logon account by checking to see if the IUSR_MACHINE account has permission to view the file. If the NTFS permissions on the file do not allow IUSR_MACHINE access to the requested page, IIS returns an HTTP 401 Unauthorized status code to the browser.

 At this point the browser attempts to authenticate the user using one of the other authentication methods. If Windows NT Challenge/Response is used, the browser automatically returns the appropriate information to satisfy the authentication request. The user is not prompted for a username and password unless the server does not recognize the username provided by Windows NT Challenge/Response. If Basic authentication is used, the user is prompted for his or her username and password. IIS then checks the user’s credentials against the access permissions on the requested page, and either returns the page to the browser or returns an Access Denied response......

Course ASP :  Troubleshooting Tips and Techniques