[ic] CookieName directive fails

[Kevin Walsh]

Mike Heins [mike at perusion.com] wrote:
> Quoting Kevin Walsh (kevin at cursor.biz):
> > To be honest, I can't see the point of the CookiePatern at all and,
> > given its problems, I'm wondering if anyone is actually making any
> > use of it at all in its current form.
> >
> Yes, there is at least one catalog using it. And that catalog happens
> to have the pattern that fits what CookiePattern defaults to.
> 
> If we were to use your patch, a cookie could never have a non-word
> character value. This is not acceptable, alas. I know quite a few
> session id types that have at least '-' in them, and I know of one
> that has a ':' in it.
>
Do you mean the session ID itself?  I thought that was just randomly
generated with Vend::Util::random_string(), using the $random_chars
value ([A-Za-z0-9] minus [O01l]).  That would be captured by the
existing default (\w{8,32}) pattern.  The current CookiePattern
directive allows other patterns to be matched, but that doesn't affect
the Session ID generation.  The only reason to use CookiePattern at
the moment, as far as I can see, is because it's required when using
the CookieName directive.

The default (hard-coded) cookie pattern allows for ':' (separating
the ID from the IP/user/host) and chars like '-' and '@' in the middle
of a user/hostname.  My patch proposal shouldn't have removed any
of that, so I would expect existing setups to work without change.

Correct me if I'm wrong.  I have been known to be. :-)

The current (\w{8,32}) could be changed to ([-\w:.]+?), which would
allow for a more liberal session ID match and still fit in with the
patch proposal.  I can't see that as being necessary at the moment,
unless people are creating their own session ID naming schemes for
some reason.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin at cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/