For Programmers: Free Programming Magazines  


Home > Archive > PHP DB > April 2004 > Re: [PHP-DB] Session









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: [PHP-DB] Session
Mikael grön

2004-04-27, 4:51 am

Session objects has nothing to do with weak network connections.
If your sessions gets un-set, it's most probably because you forgot the

session_start();

command in the beginning of some file that is using sessions. Without
that line, no sessions will be neither stored nor read.

Mike


On Apr 27, 2004, at 07:46, Ng Hwee Hwee wrote:

> Hi,
>
> I have a problem with my session variables. I set them using for e.g.,
> $_SESSION["user"]=$name;
>
> However, because of weak network links, somehow my $_SESSION variables
> get unset. Is there a way to still keep the session variables even
> though the network is unstable?? i.e. as long as my browser is open,
> is there a way to still store my session variables? by the way, i'm
> not referring to the session ids, I'm referring to the variables that
> i wanted to session_register().
>
> Thank you.
>
> Regards,
> Hwee

Ng Hwee Hwee

2004-04-27, 5:54 am

thanx Wendell for your suggestion.

apparently i tried using cookies, but my cookies also get deleted after my
session is "disconnected". (?!?!)
i did not set an expiry date to my cookies because i need them to be deleted
when the user closes his browser.
what could i have done wrong??

----- Original Message -----
From: "Wendell Frohwein" <wendell@3rdpixel.com>
To: "'Ng Hwee Hwee'" <hhwee@towa.com.sg>
Sent: Tuesday, April 27, 2004 3:00 PM
Subject: RE: [PHP-DB] Session


> Im sure you can store the session ID in a cookie. Then this will save
> all your variables.
>
>
> I hope this helps.
>
>
> Wendell
>
>
>
> -----Original Message-----
> From: Ng Hwee Hwee [mailto:hhwee@towa.com.sg]
> Sent: Monday, April 26, 2004 11:46 PM
> To: DBList
> Subject: [PHP-DB] Session
>
> Hi,
>
> I have a problem with my session variables. I set them using for e.g.,
> $_SESSION["user"]=$name;
>
> However, because of weak network links, somehow my $_SESSION variables
> get unset. Is there a way to still keep the session variables even
> though the network is unstable?? i.e. as long as my browser is open, is
> there a way to still store my session variables? by the way, i'm not
> referring to the session ids, I'm referring to the variables that i
> wanted to session_register().
>
> Thank you.
>
> Regards,
> Hwee
>
>

Ng Hwee Hwee

2004-04-27, 5:54 am

thanx Mike,

i'm sure i have session_start() on all my pages. Why I'm so confident is
because my session gets unset occassionally and not everytime. i cannot find
a pattern and so it is not a consistent problem.. it's so unpredictable!
what could be the problem??

----- Original Message -----
From: "Mikael Grön" <emgee@cwazy.co.uk>
To: "Ng Hwee Hwee" <hhwee@towa.com.sg>; <php-db@lists.php.net>
Sent: Tuesday, April 27, 2004 3:54 PM
Subject: Re: [PHP-DB] Session


> Session objects has nothing to do with weak network connections.
> If your sessions gets un-set, it's most probably because you forgot the
>
> session_start();
>
> command in the beginning of some file that is using sessions. Without
> that line, no sessions will be neither stored nor read.
>
> Mike
>
>
> On Apr 27, 2004, at 07:46, Ng Hwee Hwee wrote:
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Torsten Roehr

2004-04-27, 6:44 am

"Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
news:00ae01c42c33$d9d47430$800101df@hwee
hwee...
> thanx Mike,
>
> i'm sure i have session_start() on all my pages. Why I'm so confident is
> because my session gets unset occassionally and not everytime. i cannot

find
> a pattern and so it is not a consistent problem.. it's so unpredictable!
> what could be the problem??


Take alook at this option:

ini_set('session.gc_maxlifetime', 3600); // 3600 seconds

If you don't set it the standard value is 1440 seconds, then your session
data is deleted based on the garbage probablility. Take a look here:

http://de3.php.net/session

Look out for "session.gc_maxlifetime" and "session.gc_probability".

Regards, Torsten

[color=darkred]
>
> ----- Original Message -----
> From: "Mikael Grön" <emgee@cwazy.co.uk>
> To: "Ng Hwee Hwee" <hhwee@towa.com.sg>; <php-db@lists.php.net>
> Sent: Tuesday, April 27, 2004 3:54 PM
> Subject: Re: [PHP-DB] Session
>
>
Ng Hwee Hwee

2004-04-27, 7:44 am

Hi Torsten,

That is a wonderful insight!!! :o) thanxxx!

okie, my 'session.gc_maxlifetime' = 1440 and session.gc_probability = 1.

so, should I change it to something like 43,200 (12hours*60mins*60sec)?? for example, one person works a maximun of 12 hours a day. But does it mean that by lengthening this value, the session will still be kept even if the user closes his browser??

Please advice!

looking forward to solving this!!

many thanks,
Hwee


----- Original Message -----
From: "Torsten Roehr" <roehr@zilleon.com>
To: <php-db@lists.php.net>
Sent: Tuesday, April 27, 2004 6:07 PM
Subject: Re: [PHP-DB] Session

[color=darkred]
> "Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
> news:00ae01c42c33$d9d47430$800101df@hwee
hwee...
> find
>
> Take alook at this option:
>
> ini_set('session.gc_maxlifetime', 3600); // 3600 seconds
>
> If you don't set it the standard value is 1440 seconds, then your session
> data is deleted based on the garbage probablility. Take a look here:
>
> http://de3.php.net/session
>
> Look out for "session.gc_maxlifetime" and "session.gc_probability".
>
> Regards, Torsten
>
>

Torsten Roehr

2004-04-27, 7:44 am

Hi Hwee,

of course you could set it to 43200 seonds if you want. The
session.gc_probability value should stay 1 which means that the session data
is deleted with a probability of 1 percent.

The session life time itself is not critical - the life time of the session
DATA is. Which means you should unset all session data after the desired
period of time. Maybe it's easier for you to use a ready-made package like
PEAR::Auth or PEAR::LiveUser:

http://pear.php.net/package/Auth
http://pear.php.net/package/LiveUser


Hope this helps,

Regards, Torsten

[color=darkred]
"Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
news:00d201c42c41$9d3ec710$800101df@hwee
hwee...
Hi Torsten,

That is a wonderful insight!!! :o) thanxxx!

okie, my 'session.gc_maxlifetime' = 1440 and session.gc_probability = 1.

so, should I change it to something like 43,200 (12hours*60mins*60sec)?? for
example, one person works a maximun of 12 hours a day. But does it mean that
by lengthening this value, the session will still be kept even if the user
closes his browser??

Please advice!

looking forward to solving this!!

many thanks,
Hwee


----- Original Message -----
From: "Torsten Roehr" <roehr@zilleon.com>
To: <php-db@lists.php.net>
Sent: Tuesday, April 27, 2004 6:07 PM
Subject: Re: [PHP-DB] Session

[color=darkred]
> "Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
> news:00ae01c42c33$d9d47430$800101df@hwee
hwee...
> find
>
> Take alook at this option:
>
> ini_set('session.gc_maxlifetime', 3600); // 3600 seconds
>
> If you don't set it the standard value is 1440 seconds, then your session
> data is deleted based on the garbage probablility. Take a look here:
>
> http://de3.php.net/session
>
> Look out for "session.gc_maxlifetime" and "session.gc_probability".
>
> Regards, Torsten
>
>
the[color=darkred]
e.g.,[color=darkred]
variables[color=darkred]
that[color=darkred]
Ng Hwee Hwee

2004-04-27, 7:44 am

Hi Torsten,

Thank you! Thank you!

just would like to clarify what do you mean by

>The session life time itself is not critical - the life time of the session
> DATA is. Which means you should unset all session data after the desired
> period of time.


does it mean that if I set 'session.gc_maxlifetime' = 43200 and then make
sure my user logoff, where my logoff script unset all the sessions, then I'm
on a safe track? I'm designing an intranet, so I can instruct my staff to
logoff and not just close the browser. Will this be okay? I'm not familar
with PEAR yet, but surely would like to learn more about it in future!!

look forward to your reply!

thanks again,
Hwee

----- Original Message -----
From: "Torsten Roehr" <roehr@zilleon.com>
To: <php-db@lists.php.net>
Sent: Tuesday, April 27, 2004 6:48 PM
Subject: Re: [PHP-DB] Session


> Hi Hwee,
>
> of course you could set it to 43200 seonds if you want. The
> session.gc_probability value should stay 1 which means that the session

data
> is deleted with a probability of 1 percent.
>
> The session life time itself is not critical - the life time of the

session
> DATA is. Which means you should unset all session data after the desired
> period of time. Maybe it's easier for you to use a ready-made package like
> PEAR::Auth or PEAR::LiveUser:
>
> http://pear.php.net/package/Auth
> http://pear.php.net/package/LiveUser
>
>
> Hope this helps,
>
> Regards, Torsten
>
>
> "Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
> news:00d201c42c41$9d3ec710$800101df@hwee
hwee...
> Hi Torsten,
>
> That is a wonderful insight!!! :o) thanxxx!
>
> okie, my 'session.gc_maxlifetime' = 1440 and session.gc_probability = 1.
>
> so, should I change it to something like 43,200 (12hours*60mins*60sec)??

for
> example, one person works a maximun of 12 hours a day. But does it mean

that
> by lengthening this value, the session will still be kept even if the user
> closes his browser??
>
> Please advice!
>
> looking forward to solving this!!
>
> many thanks,
> Hwee
>
>
> ----- Original Message -----
> From: "Torsten Roehr" <roehr@zilleon.com>
> To: <php-db@lists.php.net>
> Sent: Tuesday, April 27, 2004 6:07 PM
> Subject: Re: [PHP-DB] Session
>
>
is[color=darkred]
cannot[color=darkred]
unpredictable![color=darkred]
session[color=darkred]
> the
Without[color=darkred]
> e.g.,
> variables
open,[color=darkred]
i'm[color=darkred]
> that
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Torsten Roehr

2004-04-27, 8:48 am

"Ng Hwee Hwee" <hhwee@towa.com.sg> wrote in message
news:00dd01c42c46$30e76360$800101df@hwee
hwee...
> Hi Torsten,
>
> Thank you! Thank you!
>
> just would like to clarify what do you mean by
>
session[color=darkred]
>
> does it mean that if I set 'session.gc_maxlifetime' = 43200 and then make
> sure my user logoff, where my logoff script unset all the sessions, then

I'm
> on a safe track? I'm designing an intranet, so I can instruct my staff to
> logoff and not just close the browser. Will this be okay? I'm not familar
> with PEAR yet, but surely would like to learn more about it in future!!


If you unset all session data you should be safe, but it's better to REALLY
destroy all session data with session_destroy() - take a look at the manual:
http://de.php.net/session_destroy

This should be called when your users logout. The is the preferred way to
end the session. Your users should not just close the browser window - the
session will still be active then and all session data would still be
available if someone gets hold of the session id. After the logout you
should redirect to the login screen WITHOUT forwarding the session id so
that a new session is started.

I'm not familiar with PEAR::Auth nor PEAR::LiveUser - take a look at it and
decide if it's what you want. I'm using the PEAR::HTTP_Session package to
control the session data and have my own Auth class to check if a user is
logged in, the session is expired and so on.

Regards, Torsten

[color=darkred]
>
> look forward to your reply!
>
> thanks again,
> Hwee
>
> ----- Original Message -----
> From: "Torsten Roehr" <roehr@zilleon.com>
> To: <php-db@lists.php.net>
> Sent: Tuesday, April 27, 2004 6:48 PM
> Subject: Re: [PHP-DB] Session
>
>
> data
> session
like[color=darkred]
> for
> that
user[color=darkred]
confident[color=darkred]
> is
> cannot
> unpredictable!
> session
forgot[color=darkred]
> Without
even[color=darkred]
> open,
> i'm
John W. Holmes

2004-04-27, 9:34 am

From: "Ng Hwee Hwee" <hhwee@towa.com.sg>

> okie, my 'session.gc_maxlifetime' = 1440 and session.gc_probability = 1.
>
> so, should I change it to something like 43,200 (12hours*60mins*60sec)??
> for example, one person works a maximun of 12 hours a day. But does
> it mean that by lengthening this value, the session will still be kept

even
> if the user closes his browser??


Setting your gc_maxlifetime to that means that the server will not delete
the users session data files until they are over 43200 seconds old, meaning
the user hasn't requested a page in over 12 hours.

The session does not exist past the point of closing the browser unless you
increase the lifetime of the session cookie itself. I would recommend you
just leave it at zero, though, meaning it only persists for as long as the
browser window is open. The longer you make the sessions last, the easier it
is for someone to hijack them.

---John Holmes...
Hans Lellelid

2004-04-27, 12:03 pm

Hi -

John W. Holmes wrote:
> The session does not exist past the point of closing the browser unless you
> increase the lifetime of the session cookie itself. I would recommend you
> just leave it at zero, though, meaning it only persists for as long as the
> browser window is open. The longer you make the sessions last, the easier it
> is for someone to hijack them.


One point of clarification here. The *cookie* doesn't exist past the
point of closing the browser, but the session file (assuming using
files) will continue to exist until it has been garbage collected or
until session_destroy() is called. Also, if you weren't using cookies
(were passing session id in URL) you could open your browser again and
navigate back using your history & you'd still be logged in. That's why
it's a good idea to always call session_destroy() when a user logs out.
That will effectively delete all session data on the server.

Of course, as John mentions, once the user closes the browser the
in-memory cookie will be deleted and (if you're using only cookies)
there's no longer any connection between that client computer and the
session stored on the server. In that respect the "session" exists no
longer, but as mentioned the data will still be there on the server. If
someone knows (e.g. hijacker) the session ID, they can revive the
session by just adding it to the URL.

On that note, here are a few things you might want to consider if you
want to make sessions more secure:

- use only cookies for sessions. (session.use_only_cookies = 1) This
prevents the session ID from *ever* being added to the URL. URLs get
logged -- by apache, by proxy servers, by user bookmarks :) -- and if a
URL contains a session ID then you have that mentioned problem where a
session can be easily revived after the user closes the browser
(effectively session hijacking, intentional or not).

- regenerate the session id when a user logs in. simply run
session_regenerate_id() after the username/password has been verified.
This goes a long way to prevent session fixation, another type of
session attack in which an attacker makes a user log in using a fixed
session id (e.g. by clicking on a link that includes something like
&PHPSESSID=1234); once the user logs in using this fake session id, the
attacker can use that session id in order to have access to the system
as whichever user logged in. (Do a search on "session fixation" for
more information on that.)

- keep your gc_maxlifetime as small as possible; that way if a user does
close their browser their session won't remain active for 12+ hours.
You might want to consider ways of periodically refreshing the page
using an iframe or even just a <meta refresh...> solution. That will
address the need to stay logged-in while the browser is open, while also
allowing you to have a very brief session lifetime.

Hans
John W. Holmes

2004-04-27, 12:03 pm

From: "Hans Lellelid" <hans@appliedsec.com>

> - keep your gc_maxlifetime as small as possible; that way if a user does
> close their browser their session won't remain active for 12+ hours.
> You might want to consider ways of periodically refreshing the page
> using an iframe or even just a <meta refresh...> solution. That will
> address the need to stay logged-in while the browser is open, while also
> allowing you to have a very brief session lifetime.


Excellent points, Hans.

One other thing to add. When a user requests a page and you determine that
their session is not valid (probably because they've been inactive too long
and the garbage collection deleted their session file), start a new session
and store the filename and query string of the request before you redirect
back to the login page. Then, after you validate any login, check for the
existance of a saved page and query string and redirect there instead of
your page page.

The end result is a lot cleaner for the user. Sure, they'll have to log in
again, but they'll be redirected right back to the page they requested,
anyhow. You end up with shorter session files making hijacking harder and
less frustration from the user having to navigate back to wherever they
were.

---John Holmes...
Torsten Roehr

2004-04-27, 12:04 pm

> On that note, here are a few things you might want to consider if you
> want to make sessions more secure:
>
> - use only cookies for sessions. (session.use_only_cookies = 1) This
> prevents the session ID from *ever* being added to the URL. URLs get
> logged -- by apache, by proxy servers, by user bookmarks :) -- and if a
> URL contains a session ID then you have that mentioned problem where a
> session can be easily revived after the user closes the browser
> (effectively session hijacking, intentional or not).


This might be the way to go for an intranet application, like Hwee is going
to do, but not for a website with a wide audience because you are reliant on
the user's client (browser) accepting cookies. One could log the user's user
agent ident string or his ip address and check those with every page request
for further security.

Anyway, very good pieces of advice. Thanks, Hans!

Regards, Torsten
Sukanto Kho

2004-04-27, 10:35 pm

Hi, I have a problem in handling session... so I just reply in this topic.

I have created a site... when user login from one browser ..i set a
session['user']....

the problem is that when user open another browser ...he is not login ...he
have to login again...

So that 1 pc may login as 2 or more different user from different browser...

Nicholas Sk2
Daniel Clark

2004-04-27, 10:35 pm

Depends on the browser. IE and Netscsape handle opening another window
differently.

> Hi, I have a problem in handling session... so I just reply in this topic.
>
> I have created a site... when user login from one browser ..i set a
> session['user']....
>
> the problem is that when user open another browser ...he is not login
> ...he
> have to login again...
>
> So that 1 pc may login as 2 or more different user from different
> browser...
>
> Nicholas Sk2
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Marcjon Louwersheimer

2004-04-27, 10:35 pm

Do you mean a new browser window or a new browser? Like using IE first
and then netscape? If it's the latter, it wont be saved. It generates a
new session ID and wont use the same session as the first browser.
--
Marcjon
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com