469,573 Members | 1,685 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,573 developers. It's quick & easy.

Session ID, 'loosing it' between pages?

Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).

Is it really possible? Where could I find a definitive answer to that
question? What browsers does that apply to?

My database stores some information based on the session id, would there be
another, (better), way of doing things?
I know I could pass the Session ID from pages to pages but is there a better
way?

Many thanks in advance.

Sims
Jul 17 '05 #1
11 3021
Sims wrote:
Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).

Is it really possible? Where could I find a definitive answer to that
question? What browsers does that apply to?

My database stores some information based on the session id, would there be
another, (better), way of doing things?
I know I could pass the Session ID from pages to pages but is there a better
way?

Many thanks in advance.

Sims


I prefer a method that works like this:
(1) Store a session ID in a secure client cookie and in a server-side
database. Read the cookie containing the session ID only
over a secure SSL connection.
(2) Check the session ID in the cookie on every page the user visits,
use it to retrieve the access level (stored only server-side).
(3) Make sure the session ID meets the following criteria:

(a) the cookie has not expired.
(b) it's not expired server-side either.
(c) it matches the IP it was originally created with.
(d) other criteria: for example, it was created with the
same client browser, etc.
(e) anything else you might add.

If any one of the criteria fails, the user gets a "no access" message
and must login again.
Jul 17 '05 #2
In message <2o************@uni-berlin.de>, Sims
<si*********@hotmail.com> writes
Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).

Is it really possible? Where could I find a definitive answer to that
question? What browsers does that apply to?

My database stores some information based on the session id, would there be
another, (better), way of doing things?
I know I could pass the Session ID from pages to pages but is there a better
way?


The easiest way to "lose" the session id is to forget to call
session_start() for every single page!

--
Rob...
Jul 17 '05 #3
Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).

Is it really possible? Where could I find a definitive answer to that
question? What browsers does that apply to?

My database stores some information based on the session id, would there beanother, (better), way of doing things?
I know I could pass the Session ID from pages to pages but is there a betterway?


The easiest way to "lose" the session id is to forget to call
session_start() for every single page!


I do call session_start() at every page, and I never lost an ID, but I want
to make sure that the session ID is not 'lost' by actions of the user.
What I am talking about is not server side but 'user' side. Is there a
browser, action, anything that the user could do to make me 'loose' my
session ID.

I understand that they could switch their computer off and I would loose the
number then.

Sims
Jul 17 '05 #4
Sims wrote:
I do call session_start() at every page, and I never lost an ID, but I want
to make sure that the session ID is not 'lost' by actions of the user.
What I am talking about is not server side but 'user' side. Is there a
browser, action, anything that the user could do to make me 'loose' my
session ID.
Well yeah, for most of your users (if your site isn't addressed to a
particular group of [unix] users): BSOD (blue screen of death, windows
blowing...). But then the problem is solved, the user has to re-login.

No i don't think there's any reason why you should be worried about
loosing the session ID. If it's not present, just consider the user as
not logged in and redirect him to a login page. Most of the time he'll
have tried to mess something up, so too bad for him.

Never trust the users, always make sure that whatever happens they're
getting kicked out.
I understand that they could switch their computer off and I would loose the
number then.
Well i hadn't read this, so forget about the BSOD part, you'd figured
that one out already.
Sims


Best regards,
Sebastian

--
The most likely way for the world to be destroyed,
most experts agree, is by accident.
That's where we come in; we're computer professionals.
We cause accidents.
--Nathaniel Borenstein
Jul 17 '05 #5
>
No i don't think there's any reason why you should be worried about
loosing the session ID. If it's not present, just consider the user as
not logged in and redirect him to a login page. Most of the time he'll
have tried to mess something up, so too bad for him.
I was looking at the phpbb code, (phpbb.com), and they also seem to use GET
the first time around, (the first page).
I can only assume that they are doing it that way because they are creating
their own $SID value.

But that does not make any sense to me, why would they need to pass the
session ID the first time and then not anymore.
I am just worried that there is a good reason for them to do that, (pass the
$SID as a GET the first time), that I am missing.

Never trust the users, always make sure that whatever happens they're
getting kicked out.
Of course, but I don't want to cause more trouble than need be really. I
don't mind throwing out someone who is playing around with settings but not
someone who is genuinely not doing anything wrong.


Best regards,
Sebastian


Many thanks
Sims

Jul 17 '05 #6


"Paul Bramscher" <br*************@tc.umn.edu> wrote in message
news:<cf**********@lenny.tc.umn.edu>...
Sims wrote:
Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).

when the session expires, the session is lost. that is after a period of
inactivity.

I prefer a method that works like this:
(1) Store a session ID in a secure client cookie and in a server-side
database. Read the cookie containing the session ID only
over a secure SSL connection.


if it without ssl, then there is a big security risk. msn passport use to
use this system, and they had security breaches of all kinds.

Sumeet Shroff

Prateeksha Web Design
http://www.prateeksha.com
Jul 17 '05 #7
Sims wrote:
But that does not make any sense to me, why would they need to pass
the session ID the first time and then not anymore.
I am just worried that there is a good reason for them to do that,
(pass the $SID as a GET the first time), that I am missing.


AFAIK this is because there are two methods to propagate a session id,
either by using cookies, or by using an URL parameter ($_GET). The first
time it uses both, and then sniffs if the client has cookies enabled. If
they are not, it stops using Cookies and uses the GET-method. If cookies
are enabled, as usually, GET is no longer used and the session id is
passed transparently using cookies.

see http://www.php.net/session for more information.

HTH

--
Suni

Jul 17 '05 #8

AFAIK this is because there are two methods to propagate a session id,
either by using cookies, or by using an URL parameter ($_GET). The first
time it uses both, and then sniffs if the client has cookies enabled. If
they are not, it stops using Cookies and uses the GET-method. If cookies
are enabled, as usually, GET is no longer used and the session id is
passed transparently using cookies.


Ok, but what's the point of doing that?
Why save it in a cookie? if $_SESSION does not work then there is something
wrong with the server settings.

I just don't get it really.
If sessions are server side, (and I am quite sure they are), then why the
need to place a cookie on the user machine and rely on their machine?

Otherwise that would imply that there is a possible security/loss(?) problem
with using the server side.

I wish I could test if I need to pass the number with the GET or if the
session will work.

Simon
Jul 17 '05 #9

"Sims" <si*********@hotmail.com> wrote in message
news:2o************@uni-berlin.de...

AFAIK this is because there are two methods to propagate a session id,
either by using cookies, or by using an URL parameter ($_GET). The first
time it uses both, and then sniffs if the client has cookies enabled. If
they are not, it stops using Cookies and uses the GET-method. If cookies
are enabled, as usually, GET is no longer used and the session id is
passed transparently using cookies.

Ok, but what's the point of doing that?
Why save it in a cookie? if $_SESSION does not work then there is
something
wrong with the server settings.

I just don't get it really.
If sessions are server side, (and I am quite sure they are), then why the
need to place a cookie on the user machine and rely on their machine?


The session data is stored server-side in a file which is keyed by
sessionid. Whenever the client sends a request it must contain the sessionid
so that the server can link that request to one of its numerous session
files. If a request does not contain a sessionid then this is considered to
be the start of a new session, and a new sessionid is generated with an
empty file of session data.

There are two ways of passing the sessionid - within the URL or within a
temporary cookie. The temporary cookie only lasts for the duration of that
browser instance.

The reason why you sometimes see a sessionid in the URL the first time you
visit a site is because a cookie cannot be generated and used on the first
page. You can generate a cookie on page1, but you can only test if it has
been created successfully by looking for it on page 2.

HTH.

--
Tony Marston

http://www.tonymarston.net
Otherwise that would imply that there is a possible security/loss(?)
problem
with using the server side.

I wish I could test if I need to pass the number with the GET or if the
session will work.

Simon

Jul 17 '05 #10
>
The session data is stored server-side in a file which is keyed by
sessionid. Whenever the client sends a request it must contain the sessionid so that the server can link that request to one of its numerous session
files. If a request does not contain a sessionid then this is considered to be the start of a new session, and a new sessionid is generated with an
empty file of session data.

There are two ways of passing the sessionid - within the URL or within a
temporary cookie. The temporary cookie only lasts for the duration of that
browser instance.

The reason why you sometimes see a sessionid in the URL the first time you
visit a site is because a cookie cannot be generated and used on the first
page. You can generate a cookie on page1, but you can only test if it has
been created successfully by looking for it on page 2.


I see, so could I not do something like...

if( !isset($_SESSION ))
// Use URL to get ID and db to get relevant data
// but assume first time and set it again
$_SESSION['id'] = xxx.
else
// USE $_SESSION data

So if the session is not set, (no cookies), then I will get the data from
the database otherwise I will get it from the $_SESSION.

And it should be safe enough I think.
What do you think?

Simon
Jul 17 '05 #11
Prateeksha Web Design wrote:
"Paul Bramscher" <br*************@tc.umn.edu> wrote in message
news:<cf**********@lenny.tc.umn.edu>...
Sims wrote:
Hi,

I heard that there was a chance of 'loosing' a session ID between pages,
(when the user clicks from one link to another).


when the session expires, the session is lost. that is after a period of
inactivity.

I prefer a method that works like this:
(1) Store a session ID in a secure client cookie and in a server-side
database. Read the cookie containing the session ID only
over a secure SSL connection.

if it without ssl, then there is a big security risk. msn passport use to
use this system, and they had security breaches of all kinds.


That's right, so a session ID should never be used by itself -- SSL or
not. Especially in places where there are public terminals (libraries,
internet cafes, etc.)

The PHP setcookie function has some things to tighten it up, and they
need to be utilized. SSL, readable only over the site it was created
with, etc. But more than this, I suggest not using PHP built-in
sessions, and creating one's own session system. I use a combination of
fingerprints: IP, session, datetime, and maybe some other things like
browser type, etc. reported to the session system at initial login. So
the query to pull out the valid access levels would have several AND's,
each one being another gate the user has to pass through. Another hoop
a potential hacker would need to bypass.

None of them good by themselves, but when combined together they become
much stronger.

Sumeet Shroff

Prateeksha Web Design
http://www.prateeksha.com

Jul 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.