Client-Side Session Data

[Sanders Kaufman]

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

[Rik]

Sanders Kaufman wrote:

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

Standard is that 'session-data' (So, info in $_SESSION), is normally stored
in a file with the session-id. It is not available to the user, only their
session-id is.
--
Rik Wasmus

[Vincent Delporte]

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bu***@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

If you use FireFox as your browser (Tools Cookie Editor), you'll
see that calling session_start() creates a cookie for your domain
called PHPSESSID, which disappears once the window is closed, but can
be made permanent by writting the ad hoc code in a PHP script on the
server. This session ID can then be read by server-side scripts to
identify the user whenever a page is called.

Generally speaking, no data appart from this should be located on the
client, as this makes it too easy for hackers to hit your server. If
you really must save more data in cookies, make sure they're
encrypted.

[seaside]

Sanders Kaufman schrieb:

When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?
Or is the session data being stored on the server, and just
indexed to the session token data?

Only partly related, but probably helpful:

You can configure PHP to transparently inject your current session ID
in each and any URL, which you pass back as part of HTML code. If
correctly configured, PHP switches from cookie-based sessing ID storage
to auto-inject URL-based sessionID handling.

You need to compile PHP using --enable-trans-sid- set

[Toby Inkster]

Sanders Kaufman wrote:

Or is the session data being stored on the server, and just
indexed to the session token data?

Yes.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[seaside]

Toby Inkster schrieb:

Sanders Kaufman wrote:

Or is the session data being stored on the server, and just
indexed to the session token data?

Yes.

In this case, my hint regarding transparent URL-based session injection
might in deed be of interest.

[Sanders Kaufman]

Toby Inkster wrote:

Sanders Kaufman wrote:

>Or is the session data being stored on the server, and just
indexed to the session token data?

Yes.

Thanks to all of y'all.

[Vincent Delporte]

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bu***@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?

BTW, here's an article that just came out on dangerous ways to use
cookies:

How Not To Use Cookies
http://www.informit.com/guides/print...eqNum=232&rl=1

[Rik]

Vincent Delporte wrote:

On Sun, 17 Dec 2006 23:33:23 GMT, Sanders Kaufman <bu***@kaufman. net>
wrote:

>When you have a session going, I know that PHP stores a session
token on the client, but does it keep the session *data* on the
client, as well?

BTW, here's an article that just came out on dangerous ways to use
cookies:

How Not To Use Cookies

http://www.informit.com/guides/print...eqNum=232&rl=1
Yup, it breaks down to some very simple rules:
1. HTTPS. No discussion, don't assume anything if you haven't got it.

2. Userdata belongs on the server, and stays on the server. Users know
their own password, emailadres, etc, and why transfer logged in status &
rights to and from the user? THe only place where they're needed is on the
server itself...

3. Using Cookies to keep track of logged in visitors ARE handy. They should
have random, unguessable values, and absolutely nothing to with their
actual information. Their just an random ID for you, the data that they
represent you can link on the server.

4. Do not keep users logged in. Session time out and cookies, if still
present, become useless for anyone trying to use it later. Explain that to
people who don't want to remember passwords.

5. Do not use the same ID purposefully twice (allthough it might occur,
chances should be very slim). A user logs in, and gets a random id.

6. And finally THE golden rule: never, ever trust user input. If you expect
a number, make sure it's a number. If you expect only certain characters,
make sure there are no other. If you cannot escape the fact that users have
to enter an unknown text, use the escaping tools of characters at your
disposal. Be very, very weary for SQL injection.

There are others, but these are the most important imho. There are others,
like keep a log what users do from what location, but that's usually only
needed when is has gone wrong, and you have to track it back, never save a
plain password, do not display errors in you code should it break for some
reason, error-displaying is for development, etc.
--
Rik Wasmus

[Vincent Delporte]

On Tue, 19 Dec 2006 04:31:07 +0100, "Rik" <lu************ @hotmail.com>
wrote:

>Yup, it breaks down to some very simple rules:

Thanks for the great tips.