[ic] CookieName directive fails

Mike Heins mike at perusion.com
Thu Aug 11 23:09:10 EDT 2005


Quoting Kevin Walsh (kevin at cursor.biz):
> 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.

Yes. And because the whole idea of CookieName is that you can 
accept a cookie from some other program -- i.e. not generated
by IC.

> 
> 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 patch proposal would say you need \w only, from what I could
see.

> 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.

I don't see anything wrong with changing the values. If that is
to be done, though, I suggest it be done in the catalog.cfg file
of the standard demo. Changing the default will break at least one
(though maybe not more) catalog on upgrade.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Be patient. God isn't finished with me yet.  -- unknown


More information about the interchange-users mailing list