For those who don't mind working with Javascript I have found a method of
maintaining the sessions to a minimum length. According to the Javascript
list there is no way to get the url of the site the user is going to next so
there is no way to tell if the onunload is due to a site change or the
mo
Me too. I alway try to avoid javascript. I have one workaround to the
problem that keep me from having a headache with the browser
incompatibilities. Since I already have a table in the database that deal
with the session number, timestamp and user id. All I have to do is to
detect the duplicat
On Monday 13 January 2003 18:09, Scott Fletcher wrote:
> It's no problem. We're all very interesting in finding out what can work.
>
> Maybe I can help with one of this problem. The Gecko browser does have the
> option of blocking the opening of hte unrequest window which is maybe why
> yours doe
It's no problem. We're all very interesting in finding out what can work.
Maybe I can help with one of this problem. The Gecko browser does have the
option of blocking the opening of hte unrequest window which is maybe why
yours doesn't work in Mozilla. Just wondeirng...
"Tamas Arpad" <[EMAIL
On Monday 13 January 2003 15:14, Scott Fletcher wrote:
> Let us know how it goes... The unload event had been tried also. The
> javascript have been running for a while but the network communication is a
> bit tricky, it haven't worked well.
Sorry, maybe I missed or forgot the original problem. I
Let us know how it goes... The unload event had been tried also. The
javascript have been running for a while but the network communication is a
bit tricky, it haven't worked well.
"Víã Ãðã " <[EMAIL PROTECTED]> wrote in message
004701c2b90d$5de0c440$0700a8c0@sp">news:004701c2b90d$5de0c440$0
> You da man. Unload is perfect. If the problem he mentioned before
prevents
> the browser from finishing its communication with the server you can
always
> send a wait command with sufficient time for things to finish up. I'll
> start testing in a live environment with it now. Thank you for th
help.
Larry S. Brown
Dimension Networks, Inc.
(727) 723-8388
-Original Message-
From: Tamás Árpád [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 8:03 PM
To: Larry Brown; Scott Fletcher; PHP List
Subject: Re: [PHP] session_destroy problem
> Yes, the JavaScript code can run be
> Yes, the JavaScript code can run before the browser is closed but it would
> not be finish running because the browser closing had been executed.
> Someone had tried it before and struggled with it. But that is a good
> advice, thanks for jumping in.
I really doubt that browsers doesn't run the
riginal Message-
From: Scott Fletcher [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 12:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] session_destroy problem
You meant the tab browers. Like 2 tabs... I haven't tried it but now that
you mentioned it, I'm going to have
7) 723-8388
>
> -Original Message-
> From: Scott Fletcher [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 10, 2003 12:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP] session_destroy problem
>
> Yes, the JavaScript code can run before the browser is closed but
guys have seen this tried before maybe you already know.
Larry S. Brown
Dimension Networks, Inc.
(727) 723-8388
-Original Message-
From: Scott Fletcher [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] session_destroy problem
Yes
Yes, the JavaScript code can run before the browser is closed but it would
not be finish running because the browser closing had been executed.
Someone had tried it before and struggled with it. But that is a good
advice, thanks for jumping in.
"Tamas Arpad" <[EMAIL PROTECTED]> wrote in message
On Friday 10 January 2003 17:39, Scott Fletcher wrote:
> > Javascript has a function for performing actions on window close
> That would work only if the webserver IP address is '127.0.0.1' (local
> machine), but not any other IP address. Because of the ACK synchrious
> communication that get
mension Networks, Inc.
> (727) 723-8388
>
> -Original Message-
> From: Scott Fletcher [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 10, 2003 10:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP] session_destroy problem
>
> Session Destroy will work if you pro
Scott Fletcher [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 10:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] session_destroy problem
Session Destroy will work if you provide the user a way to log out of the
website. But if the user closed the browser then that's it. Session
Des
Session Destroy will work if you provide the user a way to log out of the
website. But if the user closed the browser then that's it. Session
Destory can't be used because the browser is a client side and Session
Destroy is a server side. So, once the browser close, it doesn't contact
the server
Hi there,
So it is the browsers problem. I tested what you said and Mozilla acts as
you stated and IE does as well. I guess my question is. Is there no way to
close clear out the session when the user logs out?
The way I set things up the class that I wrote just gets the current
sessionid and doe
In my code, I usually dump session data before calling session_destroy()
like ->
$_SESSION = array(); // Now its empty
session_destroy(); // Then call session destroy.
Works for me.
Ken Nagorski wrote:
Hi there,
I have written a class that manages sessions. I have never used sessions
before
19 matches
Mail list logo
