[ic] Session always changes after first access
Grant
emailgrant at gmail.com
Tue Jun 26 09:58:47 EDT 2007
> > >> I'm having a similar problem where the session changes whenever the
> > >> first access results in a [bounce]. My redirects are done in IC in an
> > >> autoload, and I thought that must be the problem, but I moved the
> > >> redirects all the way to the very end of BOTTOM_TEMPLATE and the
> > >> problem persists. Any ideas on this one?
> > >>
> > >> - Grant
> > >
> > > Is anyone able to keep the same cookie session when the first access
> > > is a [bounce] such as:
> > >
> > > request: domain.com
> > > [bounce href="http://www.domain.com" status="301"]
> > >
> > > I really don't think so. From the behavior I've seen, the cookie is
> > > not set until after all IC page stuff is done. Maybe the right thing
> > > to do is suppress the creation of a session until after the redirects
> > > have been processed. I think that could be done by moving the
> > > redirects to httpd.conf, but is there any way to keep the redirects in
> > > IC and delay the creation of a session until after the redirects have
> > > been processed? When is the session created exactly?
> >
> > I think (I'm not digging into the code ATM so I don't know for sure)
> > that the bounce happens afterwards, but it overrides all the buffered
> > output from anything previous so cookies that were meant to be sent will
> > get lost. The best way to keep the session on a bounce is to generate
> > the bounce link properly with the session ID in the link.
> >
> > We should have some sort of parameter for bounce that will preserve cookies.
> >
> Just bounce to the page, rather than to a full URI:
>
> [bounce page=index status=301]
>
> The URI will be generated with a session ID parameter if no cookie is
> detected.
The problem with that is I use:
ScratchDefault mv_no_session 1
which basically requires session cookies and doesn't write IDs to the
URL. Is there any way to use mv_no_session and prevent the extraneous
session from being created?
- Grant
More information about the interchange-users
mailing list