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/