Hi Royce,

BTW: This code depends on the server being one and the same. After reading Nik's response it dawned on me about the IP addresses being different. Doesn't necessarily mean that there are two completely different PHP's running it though. Nor does it necessarily mean that there are two different servers. To find that out for sure check with your ISP's technical support.

I know that my secure and non secure url reference the same IP address.. I am luckily fortunate enough to have an ISP with the vision and understanding that a programmer may *need* all of that to be the same in order to make use of the SSL feature. But often times the secure server is separate from the regular server.

If the ini setting doesn't do anything for the problem.. come back to us and we can dream up a custom session handler. I've been curious about how to it anyway!

: )
Rich

:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

Hello Rich and Nik,

First of all, thanks for your thoughtful, clear, and rapid responses. Your collective insight is making this problem appear manageable. :D

Rich - I am going to test out the code you prepared and see what the results are.

Nik - the site I am developing has a dedicated IP address, with a second dedicated IP for the "secure" subdomain. I am currently hosting about 60 relatively dormant domains on this server, only a handful of which have dedicated IP's.

I have root access to this server, so I _can_ make configuration changes. However, I would rather make the code in each of my domains self-contained enough that I won't have to mess around with the .ini settings every time I build a new cart or make other mods.

I will touch base with you as soon as I see the results from the code you sent.

Rich - I have tested your code for submitting variables via the POST method, and it works as expected.

What I attempted to do last night was to pass the insecure SID via the GET method to the SSL-secured page. I then tried to overwrite the new SID (created when the new secure connection was initiated) with the insecure SID by using the session_id() function.

Admittedly, I didn't echo everything to see what was really going on, but I queried the database and found that a new SID had been created. Also, the once-full shopping cart was reported as empty (indicating that the new, secure SID was in effect).

I'll be working on this for about another hour and then I'll be away until late evening.

Thanks again,

Royce

The code provided for altering the ini directive *should* be done at
runtime, as each hosted domain isn't going to have the same needs. This
would make no sense if it were done at the root level. And this can be
designed to be ambiguous.. meaning that it can update itself to fill the
need whenever this situation presents itself in the future. And should in
theory correct the problem of new session id initiation. So this would
eliminate the need for any configuration changes at the admin level,
provided that the same installation of PHP is running both the secure and
non-secure sites thereby transcending different IP addresses and even
completely different sites all-together, the non secure domain and
subdomains can be designed to share session with the central SSL. To make
it truly ambiguous I would suggest plugging in a $_SERVER or $_ENV variable
that contains only the domain and suffix, which would allow the SSL to
accept refering sessions from either the non secure domain or its
sub-domains in any situation where there is the need to transfer the session
from one of these to the SSL domain.

Essentially you are saying to the server, allow this referring url to be one
in the same with the current as far as sessions go. And this is a tiny
amount of code and effort when compared to the alternative, creating a
custom session handler. Which in my mind I would see as the only other
solution, without serious changes to how the system is set-up.

Also, just in case there were any misunderstandings as to what ini_set()
does, this change is not permanent. It only alters the ini setting for the
lifetime of the script. So this function does not actually change
configuration in the ini file.

After looking over your responses again I was wondering if that thought had
crossed your mind.

: )
Rich

:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

No problem. PHP is a complex language! Well the forum doesn't really matter, we're likely to assume more knowledge if you post the the pro forum. But in the end it'll all come out anyway!

: )
Rich



:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

Keep in mind that writing code that alters configuration settings at run-time can only work if PHP is set up to allow those run-time changes.

Also, keep in mind that writing custom session handlers is not that difficult! If you continue to use cookies to store the session ID, you can prevent ALL The headaches you've been suffering with by specifying the domain of the cookie to encompass ALL of your sites, not just a specific one!

There are six functions you need to write in order to implement custom session handling: open, close, read, write, destroy, and garbage collection. There's already lots of decent documentation and tutorial material out there. I'd suggest starting with the PHP manual at:
  http://www.php.net/session_set_save_handler

There are also several decent tutorial articles at PHPBuilder.com:
  http://www.phpbuilder.com/

Here's a good start, though a bit outdated:
  http://www.phpbuilder.com/columns/ying20000602.php3


Finally, in defence of posting in the Pro PHP forum, it was me that started this thread. I just wanted a TIP/FAQ type posting about why session_register() is bad, and wasn't really expecting a new, albeit related, thread to be appended to it a couple months later! =)


Take care,

Nik
http://www.bigaction.org/

Hey Nik, I'm struggling with the same problem, and I'm comfortable coding my own session handler to a database, but it's not clear to me how this will help since I don't see where in the API for the sesssion handler I'm supposed to be generating my own SIDs. It looks to me that the keys for the read and write calls are generated by php, and I'm afraid that in the hash algorithm for creating keys for the session routines includes the domain of the referer as a seed, and thus will still be different between $_SESSION arrays created from SSL-accessed page and those on my non-SSL pages with a different root domain. I'm sure I'm missing something obvious....

-George

Unfortunately, what I suspected appears to be the case: I implemented a db-backed session handler, so different servers on the backend access the same place to retrive session info. The problem is that different session keys are generated from the page accessed from the SSL url than those accessed from the non-secure URL. So implementing the session handler, while i suppose is nice for use in a cluster, doesn't by itself solve this problem. I'm still poking around trying to figure out how to take over the generation of session id itself (that appears to be the $key that is passed into the session's read and write handlers). If anyone has any pointers, or if you think I'm barking up the wrong tree, please shout. Thanks a bunch.

-George Snelling