Le mardi 21 septembre 2010 à 17:59 +0200, André Warnier a écrit :
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..
>
I found it more reliable for installation over various machines, it also
makes it easier for me to use different versions of
apache/perl/postgres. Mod_ssl complicates matters a bit too, so I have
better control that way. I seem to remember that performance is also
better, according to ApacheBench.
I realized after the fact that updates _are_ a problem. I suppose one
has to recompile from source. I'm hoping to script the process,
eventually.
> 2) if you are running only 2 sites
I do have a couple other virtual hosts on the server, which is the
reason for the http only server.
I also wanted to minimize the cpu load and separate the demo account
from the main database for security reasons, which is why that account
is served from the http server, with a different database connection.
> , 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.
>
This sounds like what I'm doing now? You do need two httpd processes,
one that listens on port 80, the other on port 443.
>
> 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,
They are set the same way, both processes use the same modules.
> 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.
Save for a couple exceptions (style sheets and images), I enforce
relative links in my code, so I doubt a switch happens.
In any case, demo and registered users can log in both ways, http or
https; this does not change the logic of the database connection (see my
other reply for the code).
Their cookie is unique in my session database, and that session is tied
to their account, so they shouldn't see the demo user's data, regardless
of whether they are using https or not.
See the relevant code in the HeaderParser below :
=====================================================================
sub handler {
my $r = shift ;
#on suppose que la session n'est pas valide, jusqu'à preuve du contraire
my $redirect_to_login = 1 ;
my $j = Apache2::Cookie::Jar->new($r) ;
#get cookie from request headers
my $cookie = $j->cookies('session') ;
if (defined $cookie) {
#cookie string : session=151b733d5b92679da9177ad9c9dd7d7c
my ($key,$session_id) = split (/=/,$cookie) ;
my %session=() ;
#ne continuer que si on a une clé de session
if ( $session_id ) {
#create session
eval {
tie %session, 'Apache::Session::Postgres', $session_id, {
DataSource => 'dbi:Pg:dbname=marica_sessions',
UserName => $r->dir_config('db_user'),
Password => undef,
Commit => 1
}
} ;
#erreur avec la clé de session
if ($@) {
if ($@ =~ /^Object does not exist in the data store/) {
#session supprimée, rediriger vers login
} else {
warn $@ ;
return Apache2::Const::SERVER_ERROR
}
} else { #on a une session ; valider son time_to_live
#vérifier si la session n'a pas expiré
if ( $session{time_to_live} >= time() ) {
[...]
=====================================================================
> 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).
>
Even supposing a bad link exists, the browser always sends the same cookie,
regardless of whether it's using http or https.
