Re: $_SESSION w/o session_start()

Well, I seem to be having a problem no one else can relate to, which
means either one of two things: I've been staring at this for too long and
can't see the forest for the trees, or I'm being too opaque. Not much I
can do about the former this far in, so I'll try to rephrase--with
apologies for a rather lengthy post. If you don't want to work your way
through the rehash, please feel free to skip to the last paragraph.

My script provides basic shopping cart functionality, which relies on
access to the $_SESSION super global. Assorted sanity checks (XSS, SQL
injection, regex conformity) mean that a POST reload with previous values
might be required. This can be achieved by filling in value attributes
and/or hidden input fields, so no need for sessions here.

The only way to save state is by cookie. This is a requirement and
explicitly rules out trans id or SID session propagation. If
the client doesn't accept cookies, only one item per request will be
processed, and the user's choice will be lost should he decide to quit the
application.

Now, session_start() will create a new session file for each and
every scripted page request if there's no state (i.e., neither cookies, nor
trans id's). This is something I'd like to avoid. On the other hand, I
do not want to go through any of the server or client-side workarounds
(redirects/loads, javascript) in order to make calls to session_start() a
function of whether cookies are accepted or not. The only place where
I can do this without any coding contortions is my shopping cart script.

Using $_SESSION from within my script now becomes a somewhat dodgy
affair. All official sources state that you cannot use $_SESSION without a
prior call to session_start(). My tests show that you can, without the
interpreter complaining about an uninitialized variable. It even becomes
out-of-the-box super-duper global (I'm referencing it from within a class
method). Again, this works without any session file to de-serialize
from.

I guess what I'm really looking for is an elegant, fully sever-side
solution to the 'no cookie, no session management' situation. Heck, I'll
even settle for a set_cookie() rewrite with a meaningful return value ;-)

Mike

f'up alt.php

Michael,

> Well, I seem to be having a problem no one else can relate to, which
> means either one of two things: I've been staring at this for too long and
> can't see the forest for the trees, or I'm being too opaque. Not much I
> can do about the former this far in, so I'll try to rephrase--with
> apologies for a rather lengthy post. If you don't want to work your way
> through the rehash, please feel free to skip to the last paragraph.
>
> My script provides basic shopping cart functionality, which relies on
> access to the $_SESSION super global. Assorted sanity checks (XSS, SQL
> injection, regex conformity) mean that a POST reload with previous values
> might be required. This can be achieved by filling in value attributes
> and/or hidden input fields, so no need for sessions here.
>
> The only way to save state is by cookie. This is a requirement and
> explicitly rules out trans id or SID session propagation. If
> the client doesn't accept cookies, only one item per request will be
> processed, and the user's choice will be lost should he decide to quit the
> application.
>
> Now, session_start() will create a new session file for each and
> every scripted page request if there's no state (i.e., neither cookies, nor
> trans id's). This is something I'd like to avoid. On the other hand, I
> do not want to go through any of the server or client-side workarounds
> (redirects/loads, javascript) in order to make calls to session_start() a
> function of whether cookies are accepted or not. The only place where
> I can do this without any coding contortions is my shopping cart script.
>
> Using $_SESSION from within my script now becomes a somewhat dodgy
> affair. All official sources state that you cannot use $_SESSION without a
> prior call to session_start(). My tests show that you can, without the
> interpreter complaining about an uninitialized variable. It even becomes
> out-of-the-box super-duper global (I'm referencing it from within a class
> method). Again, this works without any session file to de-serialize
> from.
>
> I guess what I'm really looking for is an elegant, fully sever-side
> solution to the 'no cookie, no session management' situation. Heck, I'll
> even settle for a set_cookie() rewrite with a meaningful return value ;-)

Just to be clear on what you are saying. You know that you can use
session_start() to easily make sure the SESSION carries between pages.
You can force it to use cookies and dissallow any transparent SID in the
URL in your php.ini.

You would prefer people allow cookies so that your application works
smoothly. BUT (and I want to make sure this is the question), you also
want to be able to support folks who have cookies disabled in their
browser?

As you said at the top, you can do some home grown thing to essentially
accomplish the same thing, but it will be messy and if your whole goal
was improved security -- you may create more holes than you plug.

It may be simpler just to tell people, to use the site 'cookies' have
to be enabled. Unless you have a unique audience, most people will
accept cookies as most sites require it.

Hope this helps.

--
John
__________________________________________________ _________________
John Murtari Software Workshop Inc.
jmurtari@following domain 315.635-1968(x-211) "TheBook.Com" (TM)
http://thebook.com/

John Murtari:

> Just to be clear on what you are saying. You know that you can use
> session_start() to easily make sure the SESSION carries between pages.

Yes.

> You can force it to use cookies and dissallow any transparent SID in the
> URL in your php.ini.

Correct. My .ini settings reflect this.

> You would prefer people allow cookies so that your application works
> smoothly. BUT (and I want to make sure this is the question), you also
> want to be able to support folks who have cookies disabled in their
> browser?

Correct. The script in question will provide a more comfortable user
experience if cookies are accepted. However, this doesn't warrant the
overhead of server-side page reloads; nor do I want to make script usage
contingent on client settings, which in turn excludes client-side checks
and alerts. To use a somewhat vainglorious example, Google's search
interface will work cookies or no, but you'll get a little extra if they're
enabled.

Right now, I session_start() by default on each and every scripted page.
Unfortunately, this will create a new session file for each and every page
invocation if there's no way to pass session id's around (i.e., the
client doesn't accept cookies). Of course, garbage collection will take
care of those orphans eventually. Call me old-fashioned, call me
paranoid, but I a.) don't like to squander system resources and b.) see
the potential for a DoS attack lurking in the background (OK, maybe I *am*
paranoid).

Now, the obvious solution would be to run a server-side test for cookies
*before* invoking session_start(), with the result of 'no cookies, no
session'. But, again, IMHO this would be overkill. The next best solution
is to at least do this from within my application script. The only
meaningful way to access that script is from pages within the same cookie
domain, so a simple empty($_COOKIE) evaluation will do the trick.

However, I'd also like to keep $_SESSION as a data repository whether
session management is enabled or not. Whether this is a sound idea _was_
my initial question to another group, which led to a slightly surreal
exchange, so this is why it ended up cross-posted over here.

I guess the _new_ question is whether (potentially lots of) bogus session
files is such a big deal after all, and/or whether there is another way to
work around this?

Any pointers greatly appreciated.

Mike

On 6 May, 14:55, Michael Ruebner <n...@lunchinglads.net> wrote:
> John Murtari:
>
> > Just to be clear on what you are saying. You know that you can use
> > session_start() to easily make sure the SESSION carries between pages.
>
> Yes.
>
> > You can force it to use cookies and dissallow any transparent SID in the
> > URL in your php.ini.
>
> Correct. My .ini settings reflect this.
>
> > You would prefer people allow cookies so that your application works
> > smoothly. BUT (and I want to make sure this is the question), you also
> > want to be able to support folks who have cookies disabled in their
> > browser?
>
> Correct. The script in question will provide a more comfortable user
> experience if cookies are accepted. However, this doesn't warrant the
> overhead of server-side page reloads; nor do I want to make script usage
> contingent on client settings, which in turn excludes client-side checks
> and alerts. To use a somewhat vainglorious example, Google's search
> interface will work cookies or no, but you'll get a little extra if they're
> enabled.
>
> Right now, I session_start() by default on each and every scripted page.
> Unfortunately, this will create a new session file for each and every page
> invocation if there's no way to pass session id's around (i.e., the
> client doesn't accept cookies). Of course, garbage collection will take
> care of those orphans eventually. Call me old-fashioned, call me
> paranoid, but I a.) don't like to squander system resources and b.) see
> the potential for a DoS attack lurking in the background (OK, maybe I *am*
> paranoid).
>
> Now, the obvious solution would be to run a server-side test for cookies
> *before* invoking session_start(), with the result of 'no cookies, no
> session'. But, again, IMHO this would be overkill. The next best solution
> is to at least do this from within my application script. The only
> meaningful way to access that script is from pages within the same cookie
> domain, so a simple empty($_COOKIE) evaluation will do the trick.
>
> However, I'd also like to keep $_SESSION as a data repository whether
> session management is enabled or not. Whether this is a sound idea _was_
> my initial question to another group, which led to a slightly surreal
> exchange, so this is why it ended up cross-posted over here.
>
> I guess the _new_ question is whether (potentially lots of) bogus session
> files is such a big deal after all, and/or whether there is another way to
> work around this?
>
> Any pointers greatly appreciated.
>
> Mike

All you've got to do is go straight to the checkout if the session is
not initialized, e.g. if our buy link points to....


<?php

if (strlen($_COOKIE[session_name()])) {
session_start();
$_GLOBALS['note_to_self']="running in session mode";
$_SESSION['basket'][]=$_GET['sku'];
} else {
header("Location: checkout.php?basket=" . $_GET['sku']"); // but
you should really use a 307 redirect
}
....?>


Of course there is an initial point where the session does not exist,
so you need to do an unconditional session_start() first. And that
means you could end up creating a lot of sessions which never get
used. While it is possible to come up with a scheme where you drop
your own cookie and see if it gets returned to check if sessions are
possible, this is probably premature optimization.


HTH

C.