The plot thickens... My login problem is session related. I connected to my
application through the Charles web proxy to watch what was happening. On
both Debian 7 and Debian 8, my login executes correctly and sends a
Set-Cookie header up to the browser with the session cookie/id. However,
the user is then redirected to my /index.pl page. On the Debian 7
server(with bit for bit identical code, Client OS, and browser) a Cookie
header is sent down to the server by the browser and everything is fine. On
the Debian 8 server(with bit for bit identical code, Client OS, and
browser) the Cookie header is not sent down to the server when accessing /
index.pl after logging in and then, because a session cookie wasn't sent to
the server, the security framework thinks that the user isn't logged in and
sends them back to the login page. What is stranger still is that once in a
blue moon I manage to log into the Debian 8 environment without issue.
My confusion is this:
1) How can the server side be the problem if sending the cookie back to the
server is the responsibility of the browser?
2) How can the server not be the problem when the only things which are
different are on the server side?
3) Why is the problem inconsistent?
....
Since writing the above, I *might* have found the problem but it's one of
those things that seems like it *shouldn't* make a difference and yet does.
>From my proxy logs, I noticed a potentially significant difference between
the cookies being sent up by the two different environments.
Debian 7: session=0f7fb992dacae8585b8ed3867613017a; path=/;
Debian 8: path=/; session=3159f5587ccd4fe82ccdbcbd1f9e87df;
I noticed that the key order is different and then went looking for the
code which was sending the cookie and found this:
==== BEGIN ====
sub set_cookie {
my ($this, $args) = @_;
my $values;
assert_hashref($args);
# Loop through the arguments and build the header
for my $key (keys %{$args}) {
$values .= sprintf("%s=%s; ", $key, $args->{$key});
}
# Set the header
$this->apache->headers_out->{'Set-Cookie'} = $values;
}
==== END ====
Remembering that hash key order is supposed to be random, I changed it to
this for testing purposes:
==== BEGIN ====
sub set_cookie {
my ($this, $args) = @_;
my $values;
assert_hashref($args);
$values .= sprintf("session=%s; ", $args->{'session'});
$values .= sprintf("path=%s; ", $args->{'path'});
# Set the header
$this->apache->headers_out->{'Set-Cookie'} = $values;
}
==== END ====
Since making that change, I haven't been able to make the Debian 8
environment misbehave. So, in answer to my own questions, my current theory
is as follows:
1) The browser may not be respecting the Set-Cookie header if it's
expecting the values to appear in a specific sequence(Though I don't know
why it would care).
2) It's possible that, in this specific scenario, there existed a bug in
the version of Perl which shipped with Debian 7 which didn't properly
randomize the hash key order and that, by pure coincidence, they were being
written into the cookie in the sequence which the browser expected.
3) The behavior on Debian may be inconsistent because the version of Perl
which shipped with it correctly randomizes the key order so that the order
of the values in the session cookie *sometimes* appear in the sequence
which the browser is anticipating.
Does that sound plausible to you guys?
On Tue, Jun 16, 2015 at 12:24 PM, John Dunlap <j...@lariat.co> wrote:
> I compiled RC3 and I'm seeing the same behavior with my application. I'll
> have to do some more digging to see if I can narrow down the problem at all.
>
> On Tue, Jun 16, 2015 at 2:16 AM, Jie Gao <j....@sydney.edu.au> wrote:
>
>> * John Dunlap <j...@lariat.co> wrote:
>>
>> > Date: Mon, 15 Jun 2015 17:20:09 -0400
>> > From: John Dunlap <j...@lariat.co>
>> > To: "Kevin A. McGrail" <kmcgr...@pccc.com>
>> > CC: Vincent Veyron <vv.li...@wanadoo.fr>, mod_perl list
>> > <modperl@perl.apache.org>
>> > Subject: Re: Apache 2.4 Upgrade
>> >
>> > Where do I get the source for 2.09-rc3? I don't see a tag for it in SVN.
>>
>> http://people.apache.org/~stevehay/mod_perl-2.0.9-rc3.tar.gz
>>
>> -Jie
>>
>>
>> > On Mon, Jun 15, 2015 at 5:12 PM, Kevin A. McGrail <kmcgr...@pccc.com>
>> wrote:
>> >
>> > > On 6/15/2015 5:02 PM, John Dunlap wrote:
>> > >
>> > > I am getting the client ip address in every request and checking it
>> > > against an access control list which is stored in my database(so that
>> the
>> > > user can maintain the ACL's without the assistance of an
>> administrator).
>> > > These are the code snippets which are grabbing the IP address:
>> > >
>> > > ==== Begin Snippet 1 ====
>> > > # Check which method is available and use the correct one. For some
>> > > # reason, remote_ip was changed to client_ip in Apache 2.4
>> > > if ($connection->can('client_ip')) {
>> > > $R->{remote_host} = $connection->client_ip();
>> > > } elsif($connection->can('remote_ip')) {
>> > > $R->{remote_host} = $connection->remote_ip();
>> > > } else {
>> > > die("I don't know how to find the client's ip address");
>> > > }
>> > > ==== End Snippet 1 ====
>> > >
>> > > ==== Begin Snippet 2 ====
>> > > if ($connection->can('client_ip')) { # Apache >= 2.4
>> > > return $connection->client_addr->ip_get;
>> > > } else { # Apache <= 2.2
>> > > return $connection->remote_addr->ip_get;
>> > > }
>> > > ==== End Snippet 2 ====
>> > >
>> > > Looks to me like someone has already made Apache 2.4 modifications to
>> the
>> > > code.
>> > >
>> > > You might want to compile the mod perl 2.09-rc3 and test with that as
>> I
>> > > don't know what SVN version debian is working with.
>> > >
>> > > regards,
>> > > KAM
>> > >
>> >
>> >
>> >
>> > --
>> > John Dunlap
>> > *CTO | Lariat *
>> >
>> > *Direct:*
>> > *j...@lariat.co <j...@lariat.co>*
>> >
>> > *Customer Service:*
>> > 877.268.6667
>> > supp...@lariat.co
>>
>>
>>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *j...@lariat.co <j...@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> supp...@lariat.co
>
--
John Dunlap
*CTO | Lariat *
*Direct:*
*j...@lariat.co <j...@lariat.co>*
*Customer Service:*
877.268.6667
supp...@lariat.co
