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