RE: [PHP] Sessions not propagated through different hosts - *Urgent!*

Addressed to: "Christopher Thompson" <ct@arborinternet.com> "Pedro Fonseca" <pedro.fonseca@iscte.pt> <php-general@lists.php.net> ** Reply to note from "Christopher Thompson" <ct@arborinternet.com> Thu, 13 Jul 2000 14:10:07 -0700 > > I did not see a response to this, and am going to come up on this > problem soon as well. Here are some of my thoughts: > > - I assume that if both standard and secure servers are on the same > machine then setting session.cookie_domain or one of its related > settings will allow the session library to resolve the user across the > two. I am guessing that you could do that across two machines in the > same Class C. I don't believe it is IP address related, it is _host name_ related. The same Class C or not does not matter, but at least the last two parts of the domain name must match. (ahappycamper.com) > > - The session information must be physically shared between all > servers, either with the same path, NFS mount, or in a commonly > accessed database. Same path? What is that? NFS will work, about as well as NFS works... Not all that well. If your NFS mount fails for any reason, your server will hang, forever, or until you restore NFS. Not a pretty picture. I do use nfs from the command line, where I am there to see if it works or not. I don't trust it enough for automated scripts or for the servers to use unattended. There have been too many kill -9 's when NFS has hung on me to trust it unattended. (A lesser kill, or a ^C will not break out of a NFS hang.) Common Database. Your best bet if you must share sessions across many servers. I've seen a MySQL session handler on the list recently, although I haven't used it myself. > > - If the machines are completely seperate, then when moving from one > machine to the other, the session ID and data would have to be passed > back and forth. The session ID would be easy to pass. The serialized > data could be passed via a form or in the URL, but this would cause > security problems unless it was encrypted. > This sounds messy to me... > Has anyone implemented the simplest case: separate HTTP and SSL > servers running on the same machine, maintaining the session across > the two? I would be interested in information about that. > Kind of... I have one instance of Apache running with a couple dozen virtual hosts on it. Most of the virtual hosts have both a secure and a non-secure section. http://www.ahappycamper.com and https://www.ahappycamper.com for example. There is only one host name, and IP address needed per secured domain that way. You can use NameVirtualHost to stack many non-secure sites on one IP address, even if they share an IP address with a secured site, but it is very hard to share secured sites on a single IP address. (The trick is alternate ports, but the best answer is separate IP addresses for each secured server.) As long as the secure param to SetCookie is 0, both sides see the cookie, and the session. (I think it is 0, it has been a long time since I messed with it. Use the setting that does not require a secure connection.) PHP4 sessions do the 'right thing'. I was a little suprised my session followed across the SSL boundary the first time I tried it. I expected to have to do _something_ to make it work. Christopher Thompson wrote: > > We are using two different (physical) computers, each with its > > own apache web server (and consequently each with its own php > > module). One of them is SSL secured and the other is not. That makes things MUCH harder. The machines have different names, different IP addreses, and separate stores for session data. If you have to keep the machines separate, I suggest you move your session data to a database, possibly with the MySQL session handler that was mentioned on this list within the last day or two. Where is your database? If it is on one of the web servers, I would suggest you make one machine web server with both secure and non-secure virtual hosts, and the other database server. If you database is already on its own machime you have two choices. There may be others, but NFS is not one of them. o Use the database machine to store session data. o Put both SSL and clear text virtual hosts on both servers, and use a load balancer that knows about sessions, or DNS tricks to keep each user coming back to the same server. You could setup your DNS like: www1 A ADDR1 www2 A ADDR2 www A ADDR1, ADDR1 (Yes, I know that is not exactly right. Lookup round-robin dns for the exact syntax.) Your VirtualHost blocks like: Server1: <VirtualHost ADDR1> ServerName www1.yourdomain.com Server2: <VirtualHost ADDR2> ServerName www2.yourdomain.com and your Links like: <A Href="http://<?=$SERVER_NAME?>/index.html"> or <A Href="https://<?=$SERVER_NAME?>/index.html"> Now round robin DNS will randomly assign each hit to www.yourdomain.com to one of the web servers in the list. Once the visitor arrives on one of the machines, the links will keep them on that same machine, and you can use simple session handling techniques on both secure and non-secure pages of your site. I don't think you will find anything faster than having session data on the local hard drive. (Maybe a local RAM-disk would be faster, but certainly nothing that moves data over your network.) The httpd.conf files will be different between the servers, but they can share the same web site code. Each will be independant of the others, and if one fails the rest will contine. > > ... two different hosts. Wasn't this not supposed to happen?, I mean > > weren't the files on the secured server supposed to continue the > > session already created by the "normal" files? Nope. I don't belive any consideration was given to having sessions work across separate machines. The closest thing to sessions that can cross machines is the MySQL session handler, and I'm not sure that even that had transparent access to sessions from one machine as a design goal. (I don't see any reason it won't work, but I haven't tried it.) Monte Ohrt wrote: > > One way to do it is submitting the session data directly between the > > two servers (not through the user's browser), then redirect the user > > to the second server. So the second server has a small app that > > waits for incoming connections from the first server and puts the > > passed session data in it's place before the user arrives. Maybe put > > a php script on inetd? This is also vice versa when going back to > > the first server. This might work, but it adds another single point of failure to the system, more network traffic, and more complexity to the system. Having a single database server is bad enough. Rick Widmer Internet Marketing Specialists www.developersdesk.com