- @whurley: i know you are the wrong person to bug, but bladelogic’s lack of revision control for packages is making my life difficult. #
- enough work, now for some fun. im going to try and implement the sunlight api reference application using deki #
- once again its 10pm and I’m cleaning up other people’s messes #
- @roebot: the deki wiki i setup for a local school is being used by 200 middle school science students now. #
- Walking to work. Nice sunny day in santa monica. #
- @roebot: im waiting to get approval from the school but im hoping to show you and MaxM something this week #
Archive for the ‘General’ Category
Twitter Updates for 2008-03-27
Thursday, March 27th, 2008information on mod_usertrack, akamai, and caching proxies
Thursday, March 27th, 2008I found the following information to be missing from the mod_usertrack docs. I’m putting it here so I don’t forget this semi-useful information. Hopefully it will also save someone else the need to read through the source code to figure this stuff out. (as a side note, I dislike reading through C code)
This information applies to the current releases of apache httpd (2.2.8, 2.0.63, and 1.3.4). Considering mod_usertrack hasn’t seen any signficant changes in years, I can’t imagine this will be outdated anytime soon.
- mod_user track generates cookie whose contents are IP + timestamp. I.E. if the IP which generates the request is 10.0.0.1 and the current unix time is 120658819, the cookie will contain: 10.0.0.1.120658819
- mod_usertrack generates this string for the cooking by calling ap_get_remote_host() and concatenating the results with apr_time_now()
- ap_get_remote_host() will returns the DNS name or the IP address of the remote host. It determines this IP based on the TCP/IP connection and NOT from the HTTP headers at Layer 7.
- As a result, if users access your web server via akamai’s content delivery network, a caching proxy, or some other intermediary the IP that returned by ap_get_remote_host() will not be the IP of the user. It will be the IP of the the intermediary (ie akamai edge server, proxy server, etc). You should therefore not count on this being the actual users IP. Get that information from the HTTP headers if you can. This will often be preserved in X-Forwarded-For, as well as other places.
- I REPEAT DO NOT COUNT ON THIS TO BEING THE ACTUAL USERS IP ADDRESS. People seem to do this quite often, even though the documentation DOES NOT say you can count on it being the users IP, or even that the cookie will contain the users IP.
- If enough users are accessing your server via the same proxy/akamai edge server/other intermediary it is possible that 2 users will end up with the same cookie value. Therefore it is theoretically possible for this value to not be unique to an individual user. Not to mention that even if it were the remote users IP, it could still be non-unique if multiple users are located behind a nat.
With all of the above items in mind, there are patches which exist to have mod_usertrack make use of X-Forwarded-For and/or mod_uuid to generate the cookie value. I’m currently working on a patch to make this a configuration directive via the apache config file. However, considering that these other patches have existed for years and have not been integrated, I have little to no hope that our patch would be.
