mod_usertrack/5023: patch to allow you to set the domain of cookies for usertrack tracking

[david griffin <gr...@recompile.com>]

>Number:         5023
>Category:       mod_usertrack
>Synopsis:       patch to allow you to set the domain of cookies for usertrack tracking
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Thu Sep 16 11:50:02 PDT 1999
>Last-Modified:
>Originator:     griffin@recompile.com
>Organization:
apache
>Release:        1.3.9
>Environment:
N/A
>Description:
mod_usertrack currently does not set the domain name for the cookie.  this causes the browser to only send the cookie up to the exact server name the cookie came from.  there's a couple of reasons this is not optimal.  for servers that answer to multiple server names, such as www.apache.org and apache.org, a seperate cookie would get set for each, depending on which url the user entered.  the user would appear as two seperate users.  another problem is instances where it is desirable to track users across distinct servers, such as bugs.apache.org and dev.apache.org.  the solution would be to set the domain of the cookie to .apache.org. with the directive CookieDomain.  the cookie would then get sent to all of the above mentioned servers, and there would only be one cookie per user.

alternatively, you can hard code into mod_usertrack.c.  yay.
>How-To-Repeat:
N/A
>Fix:
*** mod_usertrack_old.c	Thu Sep 16 09:46:03 1999
--- mod_usertrack.c	Thu Sep 16 09:50:00 1999
***************
*** 116,121 ****
--- 116,122 ----
  typedef struct {
      int enabled;
      char *cookie_name;
+     char *cookie_domain;
  } cookie_dir_rec;
  
  /* Define this to allow post-2000 cookies. Cookies use two-digit dates,
***************
*** 205,210 ****
--- 206,215 ----
  	new_cookie = ap_psprintf(r->pool, "%s=%s; path=/",
  				 dcfg->cookie_name, cookiebuf);
      }
+     
+     if (dcfg->cookie_domain) {
+     	new_cookie = ap_pstrcat(r->pool, new_cookie, " domain=", dcfg->cookie_domain, NULL);
+     }
  
      ap_table_setn(r->headers_out, "Set-Cookie", new_cookie);
      ap_table_setn(r->notes, "cookie", ap_pstrdup(r->pool, cookiebuf));   /* log first time */
***************
*** 344,349 ****
--- 349,362 ----
      return NULL;
  }
  
+ static const char *set_cookie_domain(cmd_parms *cmd, void *mconfig, char *name)
+ {
+     cookie_dir_rec *dcfg = (cookie_dir_rec *) mconfig;
+ 
+     dcfg->cookie_domain = ap_pstrdup(cmd->pool, name);
+     return NULL;
+ }
+ 
  static const command_rec cookie_log_cmds[] = {
      {"CookieExpires", set_cookie_exp, NULL, RSRC_CONF, TAKE1,
       "an expiry date code"},
***************
*** 351,356 ****
--- 364,371 ----
       "whether or not to enable cookies"},
      {"CookieName", set_cookie_name, NULL, OR_FILEINFO, TAKE1,
       "name of the tracking cookie"},
+     {"CookieDomain", set_cookie_domain, NULL, OR_FILEINFO, TAKE1,
+      "domain of the tracking cookie"},
      {NULL}
  };
  
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]