Re: $_SESSION w/o session_start()
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.
|