cookies and sessions

[windandwaves]

Hi Gurus

I am basically sorry that I have to bother you about this. I am a PHP
beginner and I have been studying sessions and cookies over the last few
weeks. I have learned lots, but I am missing the big picture.

Is it like this:

1. user comes to site
2. user does something (e.g. a search) that may be useful later => session
is started and cookie is planted on the users computer, containing only the
session ID
3. each page now has session_start in it
4. user is asked to log-in to access more stuff (the session now identifies
the user to allow only certain people in certain places).
5. when the user comes back later the cookie may recognise him or her as the
one from last time (how and where do you retain the person's information if
the session is lost - can that be done in a MySql database?)
6. Alternative, the user can log-in (session was saved in a MySql Database
in that case...)

I start almost all my pages like this:

session_start() ;
ini_set('sessio n.cache_limiter ', 'private');
include_once("_ connectToDBFile .php"); // contains dbcon function
$dbcheck = dbcon(); // connects to Mysql Database


What does the second line mean (I have no idea!)


Also, right now, I pass the session ID in the URL. In an earlier question,
people told me that this is necessary, but some others have told me this is
not necessary. For your information, I store variables in my session like
- name
- email address
- other contact details
so that if people fill in a form (there are lots on the site) then they do
not have to retype it.

I also store people's searches on the site, so that they can go back to
previous searches, and I allow them to create "a basket" with items.

Ideally, I would like to store each person's session in the mysql database
so that I can analyse how the site is used and so that people can come back
later to their site. because the site is mainly for travellers, i am not
sure how useful cookies are going to be. I prefer them to sign in (using
their email and a password).

Any comments on my ideas and understanding of how it all works are greatly
appreciated.

Thank you


Nicolaas

[Gordon Burditt]

Re: cookies and sessions

>I am basically sorry that I have to bother you about this. I am a PHP[color=blue]
>beginner and I have been studying sessions and cookies over the last few
>weeks. I have learned lots, but I am missing the big picture.
>
>Is it like this:
>
>1. user comes to site
>2. user does something (e.g. a search) that may be useful later => session
>is started and cookie is planted on the users computer, containing only the
>session ID
>3. each page now has session_start in it[/color]

The page had better have session_start in it well before the
user shows up. Usually you finish designing the site before
users are allowed into that section.
[color=blue]
>4. user is asked to log-in to access more stuff (the session now identifies
>the user to allow only certain people in certain places).[/color]

At this point, if you want to, you can tie the user's session to his
login, and log this fact in a database.
[color=blue]
>5. when the user comes back later the cookie may recognise him or her as the
>one from last time (how and where do you retain the person's information if
>the session is lost - can that be done in a MySql database?)[/color]

If the user logs in, you can tie the session to his login.
There are other ways to tie together disconnected sessions that are
less reliable, such as combinations of IP address, browser type,
stuff the user enters such as address or credit card number, etc.

Site customization (like preferences, saved searches, personal information,
messages, etc.) is probably better associated with a user's login rather than
a session because this information is expected to last more than one
session. Information kept over a short period of time (like entries on
page 1 of a form while the user is filling in page 3, current shopping
basket contents, etc.) is probably better kept with the session (which
doesn't rule out logging it also).

Incidentally, you can put a session save handler in that saves
sessions in a MySQL database rather than a bunch of small files.
This (or something similar) is necessary if you use round-robin
redundant web servers (so all the hits for a session are not
necessarily to the same server) but session info is supposed to be
kept consistent anyway.

[color=blue]
>6. Alternative, the user can log-in (session was saved in a MySql Database
>in that case...)
>
>I start almost all my pages like this:
>
>session_start( );
>ini_set('sessi on.cache_limite r', 'private');[/color]

It does something along the lines of telling the browser not to
cache the page, so you get a server hit for every page view,
and perhaps so the user can't go back to it with the "BACK" button.
[color=blue]
>include_once(" _connectToDBFil e.php"); // contains dbcon function
>$dbcheck = dbcon(); // connects to Mysql Database
>
>
>What does the second line mean (I have no idea!)
>
>
>Also, right now, I pass the session ID in the URL. In an earlier question,
>people told me that this is necessary, but some others have told me this is
>not necessary.[/color]

It's necessary for sessions to work for users who do NOT accept
cookies. See trans_sid for an adaptive way to use the session ID
in the URL automatically if the user does not accept cookies,
but leave it out otherwise.

*IF* there are security issues, putting the session ID in the URL
makes it a bit easier to snoop the session ID. Expiring sessions
is one way to reduce this (a snooped session ID that is too old is
treated as a new session, and the saved data discarded). Some sites
have serious security issues (snooping a session ID could result
in letting the snooper charge something to the user's credit card,
or expose his medical info). Some do not (snooping a session ID
could expose the user's preferred screen layout for the site).
[color=blue]
>- name
>- email address
>- other contact details
>so that if people fill in a form (there are lots on the site) then they do
>not have to retype it.
>
>I also store people's searches on the site, so that they can go back to
>previous searches,[/color]

This kind of information might be more appropriately stored in a
database and associated with a user's login, not the session.
[color=blue]
>and I allow them to create "a basket" with items.[/color]

This probably goes with the session until the user buys something,
unless you're logging every detail like what he put in the basket
and then took out.

Consider what happens if the user is logged in *TWICE* under the
same login (even if you really want to prohibit this - this is a
mental exercise to consider where the data should go). Shopping
baskets become unmanagable if two different people can add and
delete stuff from the same baskets. History probably should
be combined.
[color=blue]
>Ideally, I would like to store each person's session in the mysql database
>so that I can analyse how the site is used and so that people can come back
>later to their site.[/color]

It is quite possible to log every hit to a PHP page in a mysql logging
table, storing whatever information you want (session, login, what
page it was, time, stuff user entered, etc.).
[color=blue]
>because the site is mainly for travellers, i am not
>sure how useful cookies are going to be. I prefer them to sign in (using
>their email and a password).[/color]

Cookies are useful for the short term (tying together accesses in
what a user might call a session: one period of sitting at the
computer using the site. They are less useful for tying together
separated accesses (days, weeks, or months apart).

Gordon L. Burditt