The ASP engine maintains Session state with cookies; if the user's browser won't accept cookies, the ASP engine cannot maintain Session state for that user. That's because there has to be some sure method of identifying a particular browser. Given the uniqueness of IP addresses, you'd think that they would be perfect for identifying a particular browser, but no such luck. Multiple users often share an IP address or block of addresses. That's what a proxy server does—it maps the user's "real" IP address to one or more public IP addresses. The proxy then makes the request via the shared address. Therefore, it's perfectly possible for two or more browsers to access your application from the same IP address. Enter the cookie.
Cookies are text strings that a browser sends to a Web site each time it requests a page from that site. You can use HTTP headers to manipulate the contents of cookies directly, although it's much easier to use the Response.Cookies collection methods. Of course, that's all that the Response.Cookies collection does—send HTTP headers to add, alter, or delete cookies.Basically, there are two kinds of cookies:
- In-memory cookies These are held in memory, which means they disappear when you close the browser.
- Persistent cookies These are persisted to disk, which means they expire when you delete the file or when their expiration date arrives, whichever comes first.
The ASP SessionID cookie is an in-memory cookie.
Because some people don't want to accept any information that might identify them to a Web site, browsers generally have a setting that lets you refuse cookies. ASP sites typically don't work well if the browser doesn't accept cookies, because most ASP sites rely on the cookie so they can maintain session information for us.
The ASP engine writes a SessionID cookie as soon as the user requests the first file from an ASP application. The ASP SessionID cookie is in every way a normal cookie, except that it is usually invisible to your application. If you query the Request object cookie collection, you won't see the ASP SessionID cookie. You can prove it by creating the following ASP page script:
<%@Language=VBScript%>
<html><head><title>List Cookies</title></head>
<body>
<%
Dim V
If Request.Cookies.Count > 0 then
For each V in Request.Cookies
Response.Write V & "=" &
Request.Cookies(V) & "<BR>"
Next
Else
Response.Write "No Cookies"
End If
%>
</body>
</html>
Name the file and place it in a Web site. If you're using Visual InterDev, create a new Web project and call it ASPProject1, add a new ASP file, and place the code listing in it. Now use your browser to navigate to the page. You will see the text No Cookies. What happened?
Now, add one more line of code to the file, just before the end-of-script marker—the percent sign and right bracket (%>):
Response.Write "HTTP_COOKIE=" &
Request.ServerVariables("HTTP_COOKIE") & "<BR>"
This line of code displays the "raw" contents of the HTTP_COOKIE variable, without the filtering and organization applied by the ASP engine for the Request.Cookies collection. Run the file again (by refreshing the page). This time, you'll see No Cookies, and another line as well, that probably looks something like this:
HTTP_COOKIE=ASPSESSIONIDGGGQGQYE=DILDAIIBIFLCKEJCBLPCFCNI
That's the ASPSESSIONID cookie. It's a meaningless, semi-random ID that is highly likely to be unique. The ASP engine doesn't show it to you because you didn't generate it—the ASP engine did. I guess Microsoft thought it would be confusing to request the cookie count and get a 1 in response before ever setting a cookie yourself.
Consider one more interesting fact before we move on to a larger ASP project. Add this line to the end of the code listing:
Response.Write Session.SessionID
Refresh the page again. This time, you should see one additional line containing a long integer number like 411057027. The SessionID property doesn't return the SessionID cookie value at all! So will the "real" Session identifier please stand up? It turns out that the real SessionID is the long integer. The ASP engine generates the cookie as a long string of text for security reasons. It's much harder for a hacker to guess the long cookie string value than to guess the long integer value with which the cookie string is associated on the server.
No comments:
Post a Comment