Vincent Veyron wrote:
Hi,
I wrote a web application for case management (legal, insurance) with
mod_perl. The app is visible at :
http://marica.fr/
I recently purchased a
'dedibox' (http://www.online.net/serveur-dedie/offre-dedibox-v3.xhtml)
intended to host it, and configured it with Debian.
My setup is as follow :
Two instances of Apache2 sit on the server, one with mod_ssl enabled,
the other without. The former serves registered users on port 443, the
latter serves only the demo account which is visible on the home page.
Hi again.
First again a couple of personal opinions :
1) I do not think that anything that you did in terms of compiling Apache, could be the
origin of the problem which you describe.
2) It is extremely unlikely (I would say practically impossible) that two "Apache
children", if they are different processes, would get mixed up. The whole architecture of
CPUs and OS'es makes that very unlikely. You would have much bigger problems otherwise.
But a couple of things puzzle me in your setup.
1) if you are using Linux Debian, they why do you go through the trouble of compiling
Apache etc.. ? The Debian packagers have done a good job, and you can just install perl,
Apache and mod_perl with 3 commands :
apt-get install perl
apt-get install apache2
apt-get install libapache2-mod-perl2
The above takes about 2 minutes, and I do this on all our production servers, without any
problems until now. It also makes it much easier to keep the server up-to-date in terms of
security updates etc..
2) if you are running only 2 sites, of which only one is HTTPS, you could run it all in
one single Apache instance. It is no problem to run a single VirtualHost as a HTTPS host
on its own port 443, and other multiple HTTP VirtualHost's on port 80.
The problem is only when you want to run several HTTPS hosts.
I did try the first page of the demo site. I am using Firefox (with a HttpFox plugin,
usually very handly, but I did not need it here).
I can see that there was a cookie set, which in Firefox shows up as :
Host: marica.fr
name: session
path: /
secure: for any type of session
(so it is not marked secure)
I don't know of course how the cookie is set for the secure part of the site.
But if the parameters above are set the same way, then there would be a least a potential
for cookies to get mixed-up between the open and the secure part of the site.
The "https" versus "http", or the port (443 or 80), are /not/ part of that which, for a
browser, makes a cookie unique.
I do not know exactly how Apache::Session and your cookie-based authentication work, but I
suppose it is possible that some link somewhere in your application causes the users to
switch between the secure and non-secure part of the site, and that if they already have a
"session" cookie, the authentication mechanism would just accept it at face value and
direct the call to the wrong place.
Maybe one thing you could do, since these are two servers with a separate configuration,
is at least to change the name of the cookie in one of them (for example, name it
"secure-session" in the secure server). That would make them 2 separate cookies, and
maybe avoid the confusion (or show the problem right away, by popping up a login page as
soon as they click the "bad" link).
