session_destroy()

[Ken]

I am curious how others solve this problem.

After storing the data from sessions in the database. How do you handle the
session data stored on the server and cookie on the users computer.

I know how to destroy the session data and remove the cookie, but how do you
handle this problem.

I see three possibilities:

1. Do not remove the session data and cookie Security concerns?
2. Remove the cookie, but not the session data Endless storage of useless
data on the server
3. Remove the session data and cookie
The problem with item #3, if you destroy the session data after
displaying the data on the users screen, and then the user refreshes the
page, he sees a blank page.

[Erwin Moller]

Ken wrote:

Hi Ken,

Can you clarify your problem a bit more?
I am confused. :-)

I am curious how others solve this problem.

After storing the data from sessions in the database. How do you handle
the session data stored on the server and cookie on the users computer.
What excactly is it that you try to do?
Do you want to store the content of the cookie in the database?
Do you want to store the data in the session in the database?
Are you using a database to store the sessiondata in? (In contrast to using
flatfiles identified by the PHPSESSID?)
You can check this in your php.ini under:
session.save_handler = files

and where:
session.save_path = /tmp

and the name of the cookie:
session.name = PHPSESSID

I know how to destroy the session data and remove the cookie, but how do
you handle this problem.

I see three possibilities:

1. Do not remove the session data and cookie Security concerns?
If you are worried about sensitive data stored in the session, just destroy
it by hand when the user logs out or whenever you think is suitable:
// assign an empty array to session:
$_SESSION = array();
2. Remove the cookie, but not the session data Endless storage of useless
data on the server
No, PHP will destroy sessionfiles every X times somebody access a session.
So it periodically checks for old unused sessionfiles.
check you php.ini under

; Percentual probability that the 'garbage collection' process is started
; on every session initialization.
session.gc_probability = 1

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
3. Remove the session data and cookie
The problem with item #3, if you destroy the session data after
displaying the data on the users screen, and then the user refreshes the
page, he sees a blank page.

Whether the user sees a blank page when the session is lost, is up to you,
the programmer.

Regards,
Erwin Moller

[Ken]

Hi Erwin,

I do not have a problem but am interested in how others handle this.

"Should I destroy all session variables and the session cookie after I am
finished with them?"

If I destroy all session variables after the data is transferred to the
database by adding the destroy command to the final page;
if the user hits refresh F5 on the page, it goes blank.

The question I have how do others handle the not needed session variables
and session cookie?
1. Leave the session variables on the server and the session cookie on the
users computer?
2. Delete just the cookie on the users computer and leave the session data
on the server, even though it is not needed anymore?
3. Delete the session variables and session cookie?

Hope that helps.

Thanks for the response.

Ken

"Erwin Moller"
<si******************************************@spam yourself.com> wrote in
message news:40*********************@news.xs4all.nl...

Ken wrote:

Hi Ken,

Can you clarify your problem a bit more?
I am confused. :-)

I am curious how others solve this problem.

After storing the data from sessions in the database. How do you handle
the session data stored on the server and cookie on the users computer.
What excactly is it that you try to do?
Do you want to store the content of the cookie in the database?
Do you want to store the data in the session in the database?
Are you using a database to store the sessiondata in? (In contrast to

using flatfiles identified by the PHPSESSID?)
You can check this in your php.ini under:
session.save_handler = files

and where:
session.save_path = /tmp

and the name of the cookie:
session.name = PHPSESSID

I know how to destroy the session data and remove the cookie, but how do
you handle this problem.

I see three possibilities:

1. Do not remove the session data and cookie Security concerns?
If you are worried about sensitive data stored in the session, just

destroy it by hand when the user logs out or whenever you think is suitable:
// assign an empty array to session:
$_SESSION = array();

2. Remove the cookie, but not the session data Endless storage of useless data on the server

No, PHP will destroy sessionfiles every X times somebody access a session.
So it periodically checks for old unused sessionfiles.
check you php.ini under

; Percentual probability that the 'garbage collection' process is started
; on every session initialization.
session.gc_probability = 1

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

3. Remove the session data and cookie
The problem with item #3, if you destroy the session data after
displaying the data on the users screen, and then the user refreshes the
page, he sees a blank page.

Whether the user sees a blank page when the session is lost, is up to you,
the programmer.

Regards,
Erwin Moller

[Chung Leong]

"Ken" <kk******@wi.rr.com> wrote in message
news:4A*******************@twister.rdc-kc.rr.com...

I do not have a problem but am interested in how others handle this.

After setting session.auto_start set to 1 in php.ini, I don't have to mess
with non of them session_* functions no more.

[R. Rajesh Jeba Anbiah]

"Chung Leong" <ch***********@hotmail.com> wrote in message news:<zd********************@comcast.com>...

"Ken" <kk******@wi.rr.com> wrote in message
news:4A*******************@twister.rdc-kc.rr.com...

I do not have a problem but am interested in how others handle this.

After setting session.auto_start set to 1 in php.ini, I don't have to mess
with non of them session_* functions no more.

I'm curious to know the reason. (Chung's ideas are sometimes hard to follow;-) )

--
http://www.sendmetoindia.com - Send Me to India!
Email: rrjanbiah-at-Y!com

[Erwin Moller]

Ken wrote:

Hi Ken

Hi Erwin,

I do not have a problem but am interested in how others handle this.

"Should I destroy all session variables and the session cookie after I am
finished with them?"

No.
But I don't understand why you worry about the user that reloads the page.

Here is how I approach it, and I don't run into your question.
Hope this helps to clarify the issue. :-)

If you decide 'you are finished with the session', that is probably because
your visitor decides to log out or something like that.
If your visitor log out, you send him to a page (logout.php or something)
which contains some code that clearly ends the session.
If you are polite you also say to your visitor: "Your session ended, hope to
see you again soon!" or something like that.
If he reloads that page, he'll just get the same message.

suppose you stored in the session if somebody logged in correctly using some
username/password:

$_SESSION["authenticated"] = "Y";

and you check on all php-pages where authentication is needed for the
existence and correct value of $_SESSION["authenticated"].

if ($_SESSION["authenticated"] != "Y") {
// go away!
header("Location: loginhere.php");
exit;
}

OK?

Then in logout.php you only have to delete all sessionvariables by the
simple command:
$_SESSION = array();
which sets the session to an empty array, so no $_SESSION["authenticated"]
will exist.

This will not destroy the session, but will empty it, making it useless to
come back to pages that require $_SESSION["authenticated"] == "Y"

If you wonder what happens to the file after the session ends, that is
decribed in php.ini. I gave you the relavant entries in my last posting.
(session.gc_probability = 1 and the like, that detirmine when PHP decides
to do a session-garbage-collection round by checking all the sessionfiles)

But you don't have to worry about that, because the php executable will take
care of that. You can however use it to finetune the behaviour of heavily
visited sites.

To summarize:
1) Make sure you start a session with your visitor. (by cookie or
URL-rewriting)
2) store in the session all relevant data. (like if the visitor has rights
for this or that page)
3) When the user logs out: empty the session.
4) Make sure you check the session for the correct values of the visitor on
all pages where extra rights are needed.

Hope that helps!

Regards,
Erwin Moller

[Chung Leong]

"R. Rajesh Jeba Anbiah" <ng**********@rediffmail.com> wrote in message
news:ab**************************@posting.google.c om...

After setting session.auto_start set to 1 in php.ini, I don't have to mess with non of them session_* functions no more.
I'm curious to know the reason. (Chung's ideas are sometimes hard to

follow;-) )

Why not? I've yet heard an argument against using session autostart. When
it's on, $_SESSION is useable at all time. You don't need to worry about
calling session_start() and session_destroy(). The $_SESSION array
essentially becomes a place to put persistent variables. Too often people
try to implement user login session as a PHP session and end up getting
totally confused ("if session_start() is used to start a new session, why do
I have to keep calling it??!!!"). It is far easier to have a session at all
time--whether the user is logged in or not--and then use a session variable
to indicate the login state.

[Erwin Moller]

Chung Leong wrote:

"R. Rajesh Jeba Anbiah" <ng**********@rediffmail.com> wrote in message
news:ab**************************@posting.google.c om...

> After setting session.auto_start set to 1 in php.ini, I don't have to mess > with non of them session_* functions no more.

I'm curious to know the reason. (Chung's ideas are sometimes hard to

follow;-) )

Why not? I've yet heard an argument against using session autostart. When
it's on, $_SESSION is useable at all time. You don't need to worry about
calling session_start() and session_destroy(). The $_SESSION array
essentially becomes a place to put persistent variables. Too often people
try to implement user login session as a PHP session and end up getting
totally confused ("if session_start() is used to start a new session, why
do I have to keep calling it??!!!"). It is far easier to have a session at
all time--whether the user is logged in or not--and then use a session
variable to indicate the login state.

Agree 100%.
That's how I approach it after getting frustrated trying it the other way
(like you described).
Just always create a session, and store the the userid, authentication,
whatever in the session.
Works like a charm. :-)

Regards,
Erwin Moller