Myles Wakeham wrote:

>> nothing stores in $_SESSION (regardless of where that data is stored when
> the
>> session is closed e.g. filesystem or db) is sent to the client. the
> 'client
>> session id' is thing stored on the client and is sent by way of a cookie
> (normally)...
>> everything else is stored on the server and loaded in when a session is
> started
>> using the session id sent as a cookie header to determine which data to
> load.
>
>> it *sounds* like you have a misguided view of what a php session is and/or
> how it
>> works Myles.
>
> OK, I'm game to learn something, despite your assumptions and flame. But
> you have to explain it so that I can understand it because your previous
> explanation may as well be in Latin.

there was no flame intended (I did emphasis the word 'seems' in an attempt to
put that across) - my explanation was probably crap though :-)

>
> Let's start with the purpose of a Session. My understanding (and use) is so
> that I can keep semi-persistent data created in a web page available between
> the client and the PHP server, as the client moves from page to page.
> Basically it's the same as some form of persistent variable storage that
> moves through the client's application experience. Is this correct in your
> opinion?

yes and no.
the session mechanism serves as a means to allow 'state' to persist between
requests (normally) as long as a browser is open but that depends on the
session cookie parameters that are used... the persitence of 'state' (i.e.
data/settings/etc) is (as far as the php session is concerned) purely restricted
to the server. session data is not available or shared with the client
(of course one can pass data stored in the session to the client by including the
values in the [html] output somehow).

>
> Second, since the session data is available and key'd through some unique
> index key that PHP maintains, I can look it up at any point in my code to
> see what data has been stored for the session. But if the user quits their
> browser, or exceeds some timeout period, the session is lost and they must
> start again. Is this correct?

in so far as that this is the default session cookie parameters cause this
behaviour - so basically yes.

>
> Finally the main use of sessions that I understand is to try and make a
> browser work like a persistent client application would, so that data isn't
> lost between page requests. This data could be stored in a variety of
> places other than sessions, however. Like form variables, URL GET values,
> etc. A session is mainly a convenience for this. Is this correct?

yes but it's more than a convienience - assuming that your server has not been
comprimised you can be sure that the data in the session is safe and what you store
there is unknown to the client/user which is not the case when you pass information
around via GET, POST or COOKIE. (session fixation and session hijacking are seperate
issues of course)

>
> Now back to the original posters question about implementing sessions with
> Firebird. My point was why?

agreed. although php allows replacement of the default session handling mechnism
with session_set_save_handler() it's generally not worth the effort - the default
filebased handler is fast, making it faster is generally a question of using
a ramdisk (e.g. tmpfs)

> If the data is available for the 'session' for
> the user, why would you want to persistently store it in a database (other
> than for auditing or security purposes)?

auditing maybe one reason - but one can log thing to a persistent store during
request processing just as easily.

a better reason for using a database as the session storage mechanism is that
it potentially allows sharing session data between multiple frontend servers for
high capacity sites where incoming requests can be handled by one of any number of
webservers (and there is no garantee that a client's requests will be dealt with by
a single server.

>
> Regards,
> Myles
>
> ===============================
> Myles Wakeham
> Director of Engineering
> Tech Solutions US, Inc.
> Phone (480) 451-7440
> www.techsol.org
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>