 | Apache: The Definitive Guide |  |
This is all great fun, but we are trying to run a business here. Our salespeople are logging in because they want to place orders, and we ought to be able to detect who they are so we can send the goods to them automatically. This can be done, and we will look at how to do it in a moment. Just for the sake of completeness, we should note a few extra directives here.
IdentityCheck [on|off]
This causes the server to attempt to identify the client's user by querying the identd daemon of the client host. (See RFC 1413 for details, but the short explanation is that identd will, when given a socket number, reveal which user created that socket -- that is, the username of the client on his home machine.) If successful, the user ID is logged in the access log. However, as the Apache manual austerely remarks, you should "not trust this information in any way except for rudimentary usage tracking." Furthermore (or perhaps, furtherless), this extra logging slows Apache down, and many machines do not run an identd daemon, or if they do, they prevent external access to it. Even if the client's machine is running identd, the information it provides is entirely under the control of the remote machine. So you may think it not worth the trouble to use IdentityCheck.
Another way of keeping track of accesses is through a cookie, a number the server invents for each requesting entity and returns with the response. The client then sends it back on each subsequent request to the same server, so that we can distinguish between one person who accesses us six times and six people who access us once each from the same host. Not every browser does this, but Netscape does. This adds granularity to the data by keeping track not just of sites that access us, but of individual users. There is a backward compatibility problem: should we use two-digit or four-digit dates for cookies? This note, from Christian Allen ([email protected]) appears in the Apache documentation:
Subject Re: Apache Y2K bug in mod_usertrack.c
Date: Tue, 30 Jun 1998 11:41:56: -0400
Did some work with cookies and dug up some info that might be useful. True, Netscape claims that the correct format NOW is four digit dates, and four digit dates do in fact work...for Netscape 4.x (Communicator), that is. However, 3.x and below do NOT accept them. It seems that Netscape originally had a 2-digit standard, and then with all of the Y2K hype and probably a few complaints, changed to a four-digit date for Communicator.
Fortunately, 4.x also understands the 2-digit format, and so the best way to ensure that your expiration date is legible to the client's browser is to use 2-digit dates. However, this does not limit expiration dates to the year 2000; if you use an expiration year of "13", for example, it is interpreted as 2013, NOT 1913! In fact, you can use an expiration year of up to "37", and it will be understood as "2037" by both MSIE and Netscape versions 3.x and up (not sure about versions previous to those). Not sure why Netscape used that particular year as its cut-off point, but my guess is that it was in respect to Unix's 2038 problem. Netscape/MSIE 4.x seem to be able to understand 2-digit years beyond that, at least until "50" for sure (I think they understand up until "70", but not for sure).
Summary: Mozilla 3.x and up understands two digit dates up until "37" (2037). Mozilla 4.x understands up until at least "50" (2050) in 2-digit form, but also understands 4-digit years, which can probably reach up until 9999. Your best bet for sending a long-life cookie is to send it for some time late in the year "37".
CookieLog filename Server config, virtual host
CookieLog sets a filename relative to the server root for a file in which to log the cookies. It is more usual to configure a field with LogFormat and catch the cookies in the central log (see Section 11.5, "Logging the Action").
CookieTracking [on|off] Server config, virtual host, directory, .htaccess
If the user-tracking module is compiled in and CookieTracking on is set, Apache will start sending a user-tracking cookie for all requests.
CookieExpires expiry-period Server config, virtual host
This directive sets an expiration time on the cookie. Without it, the cookie has no expiration date -- not even a very faraway one The expiry-period can be given as a number of seconds, or in a format such as 2 weeks 3 days 7 hours. Valid time periods are:
years
months
weeks
hours
minutes
Add the following lines:
... <VirtualHost www.butterthlies.com> CookieTracking on CookieLog /logs/customers/cookies ...
If the same person accesses us four times, we see the following:
192217840356872314 "GET / HTTP/1.0" [18/Aug/1996:08:28:28 +0000] 304 192217840356872314 "GET / HTTP/1.0" [18/Aug/1996:08:28:30 +0000] 304 192217840356872314 "GET / HTTP/1.0" [18/Aug/1996:08:28:31 +0000] 304 192217840356872314 "GET / HTTP/1.0" [18/Aug/1996:08:28:32 +0000] 304
|  | |
| 5.9. Experiments |  | 5.11. Using .htaccess Files |
Copyright © 2001 O'Reilly & Associates. All rights reserved.