www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david griffin <grif...@recompile.com>
Subject mod_usertrack/5023: patch to allow you to set the domain of cookies for usertrack tracking
Date Thu, 16 Sep 1999 18:41:03 GMT

>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
>Originator:     griffin@recompile.com
>Release:        1.3.9
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.
*** 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,
+     }
      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"},
[In order for any reply to be added to the PR database, you need]
[to include <apbugs@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!     ]

View raw message