Associating Data with Munged URLs

Munged URLs are standard URLs that have been altered by placing an identifying parameter value into the URL string. In practice, this value is exactly the same as the ASPSessioniD cookie value. You can see this in action quite easily. Open the web.config file in your CSharpASP project. Scroll down until you see this tag:

<SessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424 sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false"

Note The SessionState tag may appear in a slightly different form on your server, depending on other machine settings.

For now, the important attribute is the cookieless="false" attribute. The attribute tells IIS to attempt to send a cookie for each new browser instance. Change the attribute so it reads cookieless="true".

<SessionState mode="InProc"

stateConnectionString="tcpip=127.0.0.1:42424 sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="true"

Next, create a new folder in the CSharpASP project called ch7 . Add a new Web Form to the ch7 folder. Name it ch7-1.aspx , change the default form ID to "Form1" and set it as the start page. In the Page_Load event, write the following code:

private void Page Load(object sender, System.EventArgs e) { if (IsPostBack) {

Response.Write("Postback<br>"); Response.Write(LinkButton1.CommandName + "=" + LinkButton1.CommandArgument + "<br>");

Response.Write("******************<br>");

LinkButton1.CommandName = "ASPSessionID"; LinkButton1.CommandArgument = Session.SessionID; Response.Write("ASPSessionID=" + Session.SessionID);

Now run the project. You'll see the screen in Figure 7.4.

The important part of the preceding URL appears just after the application name—CSharpASP. Because you changed the web.config cookieless attribute value, ASP.NET no longer attempts to send a cookie; it inserts the ASPSessionID value into the URL instead. You might think that doing so is fairly useless—after all, the page with the address currently shown in the browser window is one the browser already has. It isn't at all likely to be the next page that the browser requests—that's most likely to occur when a user clicks a link or button. Maybe ASP.NET inserts the ASPSessionID value into all the URLs on the page.

Here's a simple test. Add a link to the ch7-1 Web Form. Open the ch7-1 Web Form designer window and drag a HyperLink control from the Toolbox to the design surface. In the Properties window, change the Text property to Intercom and the NavigateURL property to http://www.intercom-interactive.com. The design surface should look like Figure 7.5.

Run the Web Form again. Did ASP.NET add the munged URL to the hyperlink? Move your cursor over it to see the link in the status bar. You'll see the hyperlink, but it hasn't been altered to contain the ASPSessionID. Of course, it wouldn't make any sense to add the ASPSessionID to an external link. You may be surprised by the fact that the SessionID shows up in the Response.Write.

How about an internal link? Close the Web Form to get back into edit mode. Add another HyperLink control. Set its NavigateURL property to ch4-1.aspx and its Text property to ch4-1. Now run the Web Form again. Does this internal link contain the ASPSessionID value? You may be surprised to find that it doesn't—I was. After all, how can ASP.NET maintain the ASPSessionID value if the link doesn't somehow return that value to the server?

VVM'JVH

Figure 7.4: The ASPSessionID cookie appears in the browser Address field when you set the session state cookieless attribute to true

Figure 7.5: Visual Studio Web Form design surface after addiog a HyperLink server control.

Although munged URLs work about as well as you can expect, they still have some problems. For example, if you have a Web Form with the URL http://myserver/mypage.aspx, and a user visits your page, maybe rummages around in your munged site for a while, then leaves and goes to another site for a few minutes, it depends on how the user returns whether the session will "stick." If the user presses the Back button to get back to your site, the munged URL will maintain the session; however, if the user types your URL into the browser or reaches your site through a bookmark, the server can no longer connect the browser to the previous session, and the user's original session is orphaned. In contrast, if your site uses cookies, a user can leave and return as often as he likes. As long as he doesn't close the browser instance, the cookie will let the server connect the user to the existing session.

You have one more option for recognizing the browser instance during repeat requests. You can maintain state yourself by placing some recognizable value in a hidden form variable. Like munged URLs, this works only if the user stays within your site or returns to your site via the Back button. The only advantage of hidden form variables over munged URLs is that the user can't modify the hidden value—not much of a consideration in most cases.

Was this article helpful?

0 0

Post a comment