473,322 Members | 1,714 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Client-Side Session Data

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?
Dec 17 '06 #1
13 2078
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
Dec 17 '06 #2
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.
Dec 18 '06 #3

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

Dec 18 '06 #4
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

Dec 18 '06 #5

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.

Dec 18 '06 #6
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.
Dec 19 '06 #7
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
Dec 19 '06 #8
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
Dec 19 '06 #9
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.
Dec 19 '06 #10
Rik wrote:
Yup, it breaks down to some very simple rules:
1. HTTPS. No discussion, don't assume anything if you haven't got it.
Amen. That IS number one rule. Every other rule takes a
backseat to it.

No matter how tight your security is, if users login over HTTP,
their credentials can be tooooo easily intercepted - making all
other security measures worthless.

Dec 19 '06 #11
On Tue, 19 Dec 2006 09:01:31 GMT, Sanders Kaufman <bu***@kaufman.net>
wrote:
>No matter how tight your security is, if users login over HTTP,
their credentials can be tooooo easily intercepted - making all
other security measures worthless.
So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?
Dec 19 '06 #12
Vincent Delporte wrote:
So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?
That will stop people stealing users login credentials, yes, *but* it's
still not completely secure, as the session ID could be intercepted and
used by an attacker.

You could make this slightly more secure by associating an IP address with
the session, and ending the session if the user's IP address changes,
though this may make things awkward for customers of certain ISPs such as
AOL that sit their customers behind a large pool of proxy servers.

If you're after the best security, keep using HTTPS for the entire session.

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

Dec 19 '06 #13
Vincent Delporte wrote:
On Tue, 19 Dec 2006 09:01:31 GMT, Sanders Kaufman <bu***@kaufman.net>
wrote:
>No matter how tight your security is, if users login over HTTP,
their credentials can be tooooo easily intercepted - making all
other security measures worthless.

So HTTPS should be used when logging on and receiving the session ID
cookie, but from then, it's OK to use HTTP?
That depends on what is happening from then.
ANY time sensitive data crosses the web, it should be over HTTPS
to prevent others from sniffing it out.

But HTTPS takes up more resources than regular HTTP. So where
sensitive data is not being shuffled about, HTTP is the better
choice.
Dec 19 '06 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: mb12036 | last post by:
All- Having a problem installing a DB2 client on a machine running AIX version 5.0. Client appeared to install one time succesfully, then was uninstalled and a reinstall was attempted. For...
7
by: CT | last post by:
Hi, This might seem like a basic question but I have some doubts, please humour me. I have a client-server application using java where each client on each machine needs to directly...
2
by: Raquel | last post by:
How do I know whether the 'runtime client' and the 'application development client' are installed on my machine? When I issue the command "db2licm -l", it gives the following output: Product...
4
by: Yasaswi Pulavarti | last post by:
On an AIX server, I used the db2install script from the command line to install the DB2 UDB 8.1 client. I applied the fix pak 7 to it. Now I need to use the client to test connections to another...
2
by: Rhino | last post by:
I am trying to verify that I correctly understand something I saw in the DB2 Information Center. I am running DB2 Personal Edition V8.2.1 on Windows. I came across the following in the Info...
1
by: luciano | last post by:
Hi everyone, I want to create a application and a webservice, application connect to web service to activate, web sevice will create a certificate to authenticate this client, for each...
2
by: Delmar | last post by:
I need to build Web Application that will generate a client to execute some operations. Each client has running silent application. Maybe somebody can advice me what can I do ? Thank you.
2
by: J Huntley Palmer | last post by:
I am having a horrific time integrating uw-imap's c-client for imap support in php. The problem is a whole bunch of "Text relocation remains referenced against symbol" errors during linking....
11
by: Wayne | last post by:
I am a one man enterprise and have been asked by a prospective client what happens to their database regarding ongoing changes etc if I get hit by a bus. Obviously my databases are distributed...
4
MMcCarthy
by: MMcCarthy | last post by:
http://bytes.com/images/howtos/projectscope_blocks.jpgAs a freelance IT consultant for over 10 years, I’ve come to appreciate well defined project scopes. A project scope is a common understanding...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.