In a sudden fit of reasonable naming, Microsoft decided to name the object that has all the data from the client request: "Request." That person has since been fired.

There are a few different ways to look at a request, but we are concerned here with the current request, or the context request. Fortunately this is the default request in the ASP.NET space. You can "intercept" that request with ASP.NET. But let's back up.

Digging up the request data

Every time a user types in a URL or clicks a button, a request is issued. Requests are processed by the server, and you can access them through the current context.

Note

Don't let the language fool you: All I mean by "current context" is the object set that ASP.NET gives you just for being there when the request is processed. In short, the class is called HttpRequest, and ASP.NET makes an instance and calls it Request. It is an instance of the HttpRequest class and is the HttpContext.Request property.

To create an environment to show you what I mean, set up a project with these steps:

1. Create a new ASP.NET project.

   I called mine Chapter 4.

2. Add a page called Request.aspx.

3. Right-click on the new Request.aspx page and set it as the start page.

4. Drag a button control onto the page in the designer.

5. Double-click the new button to get the Click event handler.

6. In the new Button1_Click method, add some code to flip through the Request object.

   protected void Button1_Click(object sender, EventArgs e)
   {
       foreach (String requestInfo in Request.Form)
       {
           Debug.WriteLine(requestInfo);
       }
   }

   What we are doing here is just looking at the context returned by the request. It is just somewhere for us to put the debugger, really.

7. Right-click on the Debug statement and resolve the System.Diagnostics reference.

8. In Page_Load, add more or less the same code, so we can see the difference between the original request and the postback.

   Notice the check for the postback statement.

   protected void Page_Load(object sender, EventArgs e)
   {
       if (!(Page.IsPostBack))
       {
           foreach (String requestInfo in Request.Form)
           {
               Debug.WriteLine(requestInfo);
           }
       }
   }

9. Put breakpoints next to the two foreach statements.

10. Press <F5> to run the application.

When you run, before the Web application appears, the application breaks on the foreach in the Page_Load method. Put your mouse over the Request object there, and you'll see something like Figure 4-1. Notice that the ContentLength is 0 and the HttpMethod is GET. This is an initial URL-based request for a page.

Now press <F10> until the Page_Load event is over the Visual Studio returns control to your Web browser. Notice that the Debug.WriteLine statement is never called. Why? ContentLength is 0. There is no Form. (Kinda like "There is no spoon.") The content is empty, because it is an initial request. The Form collection is empty. Nothing is there except the basic request information.

Press the button when the browser comes back. Visual Studio breaks again on the other foreach statement in the Button1_Click method. Put your mouse over the Request object again. Note the Form collection, shown in Figure 4-2. There are three items in it, the two hidden fields added by ASP. NET and the button that we added, Button1.

Figure 4-1. The initial request.

Figure 4-2. The form request.

This is the second type of request — the POST. It is in response to a form. This is where a lot useful information can be found.

ASP.NET and IIS do a good job of setting up markup for a client browser. You can even tell Visual Studio that you are targeting a certain browser (say, in a workgroup environment), and it will tweak the HTML it sends to the client to make it closer to the exact implementation of the HTML standard that browser supports.

You sometimes need to change the way the page is rendered on the client. More often, you need to change the way the metadata about the page is handed to the client. An HTML page has a lot more than the values you see on the screen. HttpResponse helps you to manage what you can and can't see.

If(!Request.IsAuthenticated){
  Response.Redirect("login.aspx");
}

If(Request.Querystring("ProductLineId")==4){
  Response.RedirectPermanently("http://newproduct.com")
}

To change the trust of a class, you want to decorate the class in the ASP.NET application with the hosting permission, like this:

using System;
using System.Web;
using System.Security.Permissions;

[AspNetHostingPermission(SecurityAction.Demand, Level=AspNetHostingPermissionLe
    vel.High)]
public class ApplicationClass
{
   //My Code is here.
}

So this code uses the High level. The others are None, Minimal, Low, Medium, and Unrestricted. Table 4-1 shows the general breakdown.

The most common problem is the use of None or Minimal as a permission level. I don't even know why Microsoft offers these choices. If you set the class to Minimal, nothing can get to anything so far as I have been able to figure out. Stick to High for trusted environments, and Medium for shared servers.

To make a site map, follow these steps:

With the web.sitemap file installed safely in the application, IIS now has a SiteMap collection that includes the XML file we made right there in memory. If you need to figure out what other pages are related to the page the user is viewing, you can do that. Follow these steps:

If you get interested, put a debugger in the loop, and check out that SiteMap object. It's a nice collection of the pages that have been referenced in the Web.sitemap file. Though this technology won't cure every navigational problem on every site, it is a nice, underused part of System.Web.

To get a cookie, you have to first leave a cookie. In part of the response to a client — say, after they log in — you want to tell the platform to save information in the Cookies collection.

What is even better is to store information about the session itself and have an understanding that the information will be removed from the database after some time limit. This prevents the impersonation of the user by someone who intercepts the cookie. There are a lot of options, but check out the best practices offered by Microsoft and other organizations before setting up your cookie strategy.

If I want to store information about the session in the cookie, and tell the database that my customer is using that session, I generate a Guid and save it in both places. Then I can retrieve the cookie at the next request, compare it to the available Guids in the user collection, and find the user in question.

Here is an example of setting the cookie based on session information:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Chapter_4
{
    public partial class Cookies : System.Web.UI.Page
    {
        WebUser currentUser = new WebUser();
        List<WebUser> usersInDatabase = new List<WebUser>();
        protected void Page_Load(object sender, EventArgs e)
        {

if (!Page.IsPostBack)
               {
                   //This is a first request, so we need to set the cookie
                   Guid sessionGuid = new Guid();
                   currentUser.SessionId = sessionGuid;
                   //Tell the database about the new user
                   usersInDatabase.Add(currentUser);
                   //Set the cookie
                   Response.Cookies.Add(new HttpCookie("SessionId", sessionGuid.
       ToString()));
              }
          }
       }
       //This class would be in the library somewhere,
       //not actually in this file.
       public class WebUser
       {
           public Guid SessionId { get; set; }
       }
   }

So now the user has the cookie, and the next request comes in. I need to grab the cookie from the collection and search my known user base to get the information that I need. The boldface in the code below indicates the code added:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Chapter_4
{
    public partial class Cookies : System.Web.UI.Page
    {
        WebUser currentUser = new WebUser();
        List<WebUser> usersInDatabase = new List<WebUser>();
        protected void Page_Load(object sender, EventArgs e)
        {
            if (!Page.IsPostBack)
            {
                //This is a first request, so we need to set the cookie
                Guid sessionGuid = new Guid();
                currentUser.SessionId = sessionGuid;
                //Tell the database about the new user
                usersInDatabase.Add(currentUser);
                //Set the cookie
                Response.Cookies.Add(new HttpCookie("SessionId", sessionGuid.
    ToString()));
           }
           else
           {

//The is a postback so we need to get the cookie
               string cookieSession = Request.Cookies.Get("SessionId").Value.
   ToString();
               Guid sessionGuid = new Guid(cookieSession);
               var returningUser = from u in usersInDatabase
                  where u.SessionId.ToString() == sessionGuid.ToString()
                  select u;
               foreach (var user in returningUser)
               {
                   //Better only be one
                   currentUser = user;
               }
       }
   }
   //This class would be in the library somewhere,
   //not actually in this file.
   public class WebUser
   {
       public Guid SessionId { get; set; }
   }
}

A lot of the stuff we use to store in a cookie is managed by the ASP.NET engine. Session state, the most common example (discussed earlier), is now handled by the ViewState object. You can store information in the ViewState like you would in a variable, and the information is encoded for you and kept in a special field in the markup.

ViewState has its problems, and a lot of people don't like to use it. In fact, many ASP.NET applications in enterprises have turned it off to save bandwidth and prevent poor coding practices. In these cases, a return to cookies is your best bet to maintain a constant communication with the user.