[EMAIL PROTECTED] wrote:
Tod Harter <[EMAIL PROTECTED]> wrote on 26/04/2005
20:41:47:
The problem, I THINK, is that his browser is NOT sending back the
cookie.
What exactly do you mean by 'sending back'?
I mean the browser should send the cookie back to the server with each
request. If it doesn't then the session stuff on the server side will
just create a new session, since it thinks you haven't been there before.
This means every time the server
handles a request it creates a NEW session, thus a new file... Now that
COULD be caused by the server not SETTING
the cookie in the 1st place, that I couldn't say!
The cookie is definately being set... I just checked that.
Then the question is 'does the client send it back?'
It also seems ODD that the browser doesn't get a new session when it
hits an old page. THAT makes me think the real problem is the URL the
cookie is set for. If its set for just the individual page then this is
exactly what would happen, you'd have an independent cookie (and
session) for each URL (IE for each page).
After trying to monitor the cookies, this is what I found:
1. First visit to site -> new session file created -> new cookie created
(expirey time seems to be set to the session creation time, and path is
set to the path of the page the cookie was set from)
OK, so I see 2 problems here. 1 if the expiry time is set to the session
creation time then the cookie is already expired by the time the client
gets it, clock-scew aside. 2 if the URL is the path to the exact page
where the session was created then thats the only page the cookie will
get sent back to, so that would explain having a different session per page.
2. Subsequent page requests -> no new session files -> no new cookies
3. login (setting session variables) -> no new session files -> no new
cookies
4. Subsequent page requests -> no new session files -> no new cookies
I guess the question then is when you say 'subsequent page requests' are
you only referring to the exact page you first hit? That would be
consistent with 1, but if its ANY page in your site then it seems odd,
unless your statement in 1 is innacurate.
5. Logout (session:invalidate) -> session file removed - > cookie still
exists in browser!!!
Correct. The browser will never delete cookies, just expire them after
the expiry time or kill them when you close the browser if they are
session cookies. You can OVERWRITE a cookie (ie set the same cookie name
and URL to a different value), but SOME cookie with that name WILL
continue to exist. So generally when a session is invalidated you just
end up with a new session id.
6. Subsequent page request -> new session file created -> new cookie set
(again, exriry time is set to current date and path is set to the path of
the page the cookie was set from)
Which sounds like the same state as 1 essentially.
7. quit browser and reopen -> all the session files still exist
Right, the server has no idea the browser exited...
I hae also noticed that if when I first visit the site, I enter from a
page other than / (the home page) a cookie gets set with the path value
set to that page location. As I then navigate through the site, new
cookies (and session files continue to be created (one for each new page I
visit) until I visit the home page (at which point a cookie gets set with
the path value set to '/'). From then on, no new cookies get set and no
new session files get created.
Right, thats exactly the behaviour I would imagine if the main page sets
the cookie URL to '/', and any other page sets it to that page's URL.
ALL pages need to set it to '/' (or whatever subpart of your site
cookies work with). The browser just matches the leading part of the
path section of the url with the page request, so if the cookie's URL is
'/' then that cookie gets sent back to all pages on your site, whereas
if it were say '/somedir/somepage.xsp' then it would ONLY send back THAT
cookie to THAT page, and if it was '/somedir' then it would send it back
to ANY page under '/somedir'. Probably you are getting back TWO cookies
with the same name, one for '/' and one for '/somedir/somepage.xsp', and
presumeably the session plugin just grabs the 1st one and goes with that.
I then tried deleting all cookies except for the one set at / and one at
another location... no new session files and no new cookies get created.
right, because now the session logic sees just that cookie and every
page gets that one.
I then deleted the cookie set at /... now new session files and cookies
get set for every new page request (except for page requests at the
location of the other cookie I left behind.
right.
OK. So that's all probably a bit hard to understand. But basically it
looks like the cookie gets set for a the particular URL of the page you
are on. This is fine if the first page you visit is the root page (home
page) because it seems that the validity of this cookie cascades down the
web tree, making all other page requests part of that session. However, if
you start off at a different location (ie. not the home page, or any other
page located at /), you will end up with a session file for each location.
- A bit pointless - not really the idea of a session (in my understanding
of it anyway)
Yep, so there is just a bug in how the URL gets set. Not having the code
in front of me I am not sure why that is, Michael is probably the guy to
answer that one. I think you have the solution in hand though, just fix
that URL, and perhaps take a look at that expiration time as well
because it really SHOULD be sometime in the future.
Otherwise it sounds to me like his file session store is working the way
you would expect. Every session has its own file and if you delete one
then the Apache::Session logic happily creates a new empty one for you,
and depending on the exact way the code is designed on the server side
you may get a new sessionid and cookie to boot, I just don't have the
code in front of me right now to look and see.
Yes I agree. this seems like it is functioning as it should... removing
the session file and creating a new one (and a new cookie to go with it).
So I think the problem is definately in the cookie!
Plus. Should the cookies not get deleted when you exit the browser?
Otherwise, as I have just found out. Quiting the browser and re-opening it
does not invalidate your session and log you out!!!!
If its a session cookie (IE no expiry time set) then yes. Otherwise its
a persistent cookie, and then the answer is no, you will have the same
session id until the cookie expires. The browser just stores them on
your hard drive. In some applications this is desirable, in others not.
Of course you can still invalidate the session from the server side
either with the invalidate tag of BasicSession or just by deleting
session files (or database entries if you use an RDBMS for your session
store, which is why I like to use MySQL for that...).
Michael Nachbaur wrote:
[EMAIL PROTECTED] wrote:
Running <session:invalidate> causes the current session file to be
deleted.
Hmmmm, the _file_? It should delete the session in the sessions
file,
but not the file itself.... That would cause the loss of all
sessions...
Thats right. The users session file gets physically removed from the
file system and subsequent page requests cause new files to be
created on the filesystem (one for each new page request).
This is a symptom of the "File" datastore, rather than the default
"DB_File" datastore that I believe Kjetil is using. The File
datastore is easier to purge older sessions because you can take a
look at the mtime of the file to delete it; it also helps with
debugging a site, because you can see exactly which sessions exist.
However, it also introduces a rather nasty problem of thousands of
files in a directory for popular sites. I believe this is where some
of the confusion came in.
I am not specifically telling the browser to delete cookies in my
script, I assume that session:invalidate does this as part of its
invalidation process? (when I say 'deleting the browser cookies' I
mean I have manually gone into the browser preferences and selected
'delete cookies' in an attempt to stop new files being generated on
the filesystem). Although this had no effect and the session folder
continued to fill up with new files.
I tend not to trust that feature of most browsers, as it doesn't work
as I expect it to. I haven't sat down and performed any rigorous
tests, but usually deleting a cookie will only cause the browser to
stop reporting that cookie to the server when you restart the browser.
A good way to tell if this is what is actually happening is, if you
are able, sniff your HTTP traffic and see if the browser is supplying
the offending Cookie: header. But this might be more effort than you
want to put out (I know it would be for me).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
