This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: mod_perl Mailing List <modperl@apache.org>
From: Michael A Nachbaur <mike@nachbaur.com>
Subject: Apache::Session using Frames
Date: Wed, 05 Dec 2001 14:50:02 -0800
I have been beating my head against this problem for days, to no avail.
I have tried google searches, etc., still no dice. So, I apologize for
the noise people.
I'm using Apache::Session and cookies to perform session management. In
watching the debug messages in my error_log, I can see that the cookie
is created, the session is created, and all subsequent calls correctly
loads the session. However, part of the design for my web application
requires the use of frames, with several frames containing mod_perl
generated data. Each one of those frames relies on using the session.
I wouldn't think this would be a problem, except that some of the
frames cannot tie to the datastore, and as a result create new sessions.
I would think the default behavior would block until the session is
unlocked, but this doesn't seem to be the case. I was first using
Apache::Session::Flex (For easier configuration), but have also tried
Apache::Session::MySQL, ::DB_File and ::File, all exhibit the same problem.
This site is developed using AxKit and AxKit::XSP::Session, but the
sessions are created before AxKit is even invoked so that isn't the issue.
Any suggestions? I'd like to resolve this without losing my hair. :)
===
To: "C.Hauser - IT assistance GmbH"
<c.hauser@itassistance.ch>
From: Michael A Nachbaur <mike@nachbaur.com>
Subject: Re: Apache::Session and frames
Date: Wed, 05 Dec 2001 15:26:33 -0800
> Basic Idea, what is the path argument of the cookie you are using? If the
> called pages are lying underneath different roots then the cookie
> won't be read.
>
> I even do not loose the session between windows :-)
Thanks for the prompt reply. The way I have this going, is a file at:
/index.xsp
which just performs a redirect to /callisto.xsp (so that it has a chance
to create the cookie). /callisto.xsp creates a frameset which loads,
among other things:
/folder-listing.xsp
/task-listing.xsp
/sitename.xsp
Each one of those sub pages are in their own frames, and each attempts
to load the session. Occasionally, one of them successfully loads the
original session, but the other two end up creating their own sessions.
When I call:
tie %session, 'Apache::Session::Flex', $id, \%options;
it doesn't return anything in $@, except there is no data inside
%session. Therefore, the code that checks for _session_id, thinks that
this is a new session, and goes ahead to create one.
Any ideas?
===
To: Michael A Nachbaur <mike@nachbaur.com>,
modperl@apache.org
From: Robert Landrum <rlandrum@capitoladvantage.com>
Subject: Re: Apache::Session and frames
Date: Wed, 5 Dec 2001 18:28:46 -0500
At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote:
>I have been beating my head against this problem for days, to no
>avail. I have tried google searches, etc., still no dice. So, I
>apologize for the noise people.
>
>I'm using Apache::Session and cookies to perform session management.
>In watching the debug messages in my error_log, I can see that the
>cookie is created, the session is created, and all subsequent calls
>correctly loads the session. However, part of the design for my web
>application requires the use of frames, with several frames
>containing mod_perl generated data. Each one of those frames relies
>on using the session. I wouldn't think this would be a problem,
>except that some of the frames cannot tie to the datastore, and as a
>result create new sessions.
>
>I would think the default behavior would block until the session is
>unlocked, but this doesn't seem to be the case. I was first using
>Apache::Session::Flex (For easier configuration), but have also
>tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the
>same problem.
>
>This site is developed using AxKit and AxKit::XSP::Session, but the
>sessions are created before AxKit is even invoked so that isn't the
>issue.
>
>Any suggestions? I'd like to resolve this without loosing my hair. :)
Cookies set in a parent frame are not immediatly accessable to a
child frames. It's a fun little bug that requires a full frame
reload to be detected. Another thing to watch out for are the cookie
paths. I've never used Apache::Session, so I don't know what path is
set for the cookies, but if the pages loading in the child frames
have non matching urls, then the session cookies aren't going to come
through.
Good Luck,
Rob
===
To: Michael A Nachbaur <mike@nachbaur.com>
From: Larry Leszczynski <larryl@furph.com>
Subject: Re: Apache::Session and frames
Date: Wed, 5 Dec 2001 18:46:56 -0500 (EST)
Hi Michael -
> I'm using Apache::Session and cookies to perform session management. In
> watching the debug messages in my error_log, I can see that the cookie
> is created, the session is created, and all subsequent calls correctly
> loads the session. However, part of the design for my web application
> requires the use of frames, with several frames containing mod_perl
> generated data. Each one of those frames relies on using the session. I
> wouldn't think this would be a problem, except that some of the frames
> cannot tie to the datastore, and as a result create new sessions.
We had similar problems with a frameset scheme - the browser requests the
page containing the frameset definition and then almost simultaneously
requests each of the pages that must be loaded into each frame, and
confusion ensues. What worked for us (I don't know for sure if this will
help you) was to turn on the "Transaction" flag during the session tie,
e.g.:
tie %s, 'Apache::Session::File', $id {
Directory => '/tmp/sessions',
LockDirectory => '/var/lock/sessions',
Transaction => 1
};
which should (depending on the underlying session mechanism) provide
transactional consistency. In our case it helped prevent data loss that
was occurring while each of the frameset pages was simultaneously
monkeying with the session.
===
To: "Robert Landrum" <rlandrum@capitoladvantage.com>,
From: "simran" <simran@sitesuite.org>
Subject: RE: Apache::Session and frames
Date: Thu, 6 Dec 2001 10:54:55 +1100
I have 'heard' that in some browsers there is a bug using HTTP/1.1 when they
use Keep-Alive. As they don't necessarily create another explicit tcp
connection for a request (but rather try to keep the connection alive), they
'forget' to send the Cookie headers for subsequent requests in the same
connection. It might not be the problem, but its worth checking what headers
each request (and each connection) is getting/sending...
===
To: "mod_perl Mailing List" <modperl@apache.org>
From: "Michael A Nachbaur" <mike@nachbaur.com>
Subject: Re: Apache::Session using Frames
Date: Sun, 9 Dec 2001 17:57:38 -0800
Just to let anyone who was wondering (and for the benefit of the archives),
I ended up ditching sessions all together. Instead, I'm using
Apache::AuthDBI to do authentication, and am making calls directly to my
database server to maintain state. Its not the most pleasant way of
maintaining state, but at least it works.
===
To: "Michael A Nachbaur" <mike@nachbaur.com>,
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Apache::Session using Frames
Date: Sun, 9 Dec 2001 23:24:46 -0500
> Just to let anyone who was wondering (and for the benefit
> of the archives), I ended up ditching sessions all
> together. Instead, I'm using Apache::AuthDBI to do
> authentication, and am making calls directly to my
> database server to maintain state. Its not the most
> pleasant way of maintaining state, but at least it works.
Then this won't be much help to you anymore, but here are a couple of
things that could have been happening:
- Not getting the cookies sent from all frames. You may have a race
condition involving when the cookie gets storeed and when other frames
send their requests.
- Not using the locking API correctly. You didn't post any code, but
the locking options for Apache::Session sometimes trip people up and you
may have had a misconfiguration of some kind.
Anyway, there's nothing wrong with writing directly to the database.
Apache::Session is just a convenient hash interface on top of that.
===