Skip Menu |
 

This queue is for tickets about the Catalyst-Plugin-Session CPAN distribution.

Report information
The Basics
Id: 71142
Status: open
Priority: 0/
Queue: Catalyst-Plugin-Session

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.32
Fixed in: (no value)



Subject: t/live_verify_address.t fails test 6 Content contains "VAR_logged=n.a."
My suspicion is that $ENV{REMOTE_ADDRESS} is being ignored and is just being mapped to 127.0.0.1.

I hacked up the Root.pm in a few places to report the address and it does appear to be doing just that.

Will keep poking.
t/live_verify_address.t .....
1..12
ok 2 - Content contains "logged in"
ok 4 - Content contains "session variable set"
not ok 6 - Content contains "VAR_logged=n.a."
 
# Failed test 'Content contains "VAR_logged=n.a."'
# at t/live_verify_address.t line 41.
# searched: "VAR_logged=in"
# can't find: "VAR_logged=n.a."
# LCSS: "VAR_logged="
# LCSS context: "VAR_logged=in"
[debug] 127.0.0.1
ok 8 - Content contains "logged in (without address)"
ok 10 - Content contains "session variable set"
ok 12 - Content contains "VAR_logged=in"
# Looks like you failed 1 test of 12.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/12 subtests

Download (untitled) / with headers
text/plain 2.4k
I'm wondering if the bug might be in the test script rather than the code… the other tests utilize multiple instances of Test::WWW::Mechanize::Catalyst my $ua1 = Test::WWW::Mechanize::Catalyst->new; my $ua2 = Test::WWW::Mechanize::Catalyst->new; I'm probably missing something but if you setup this test in much the same way, utilizing multiple instances, it passes without error. -------- my $ua1 = Test::WWW::Mechanize::Catalyst->new; my $ua2 = Test::WWW::Mechanize::Catalyst->new; # Initial Client $ua1->get_ok( "http://localhost/login" ); $ua1->content_contains('logged in'); $ua1->get_ok( "http://localhost/set_session_variable/logged/in" ); $ua1->content_contains('session variable set'); # Change Client $ua2->get_ok( "http://localhost/get_session_variable/logged"); $ua2->content_contains('VAR_logged=n.a.'); # Inital Client $ua1->get_ok( "http://localhost/login_without_address" ); $ua1->content_contains('logged in (without address)'); $ua1->get_ok( "http://localhost/set_session_variable/logged/in" ); $ua1->content_contains('session variable set'); # Change Client $ua1->get_ok( "http://localhost/get_session_variable/logged" ); $ua1->content_contains('VAR_logged=in'); ------- [just my $0.02] On Thu Sep 22 06:46:05 2011, KENTNL wrote: Show quoted text
> My suspicion is that $ENV{REMOTE_ADDRESS} is being ignored and is just > being > mapped to 127.0.0.1. > > I hacked up the Root.pm in a few places to report the address and it > does > appear to be doing just that. > > Will keep poking. > > t/live_verify_address.t .....1..12ok 1 - GET http://localhost/loginok > 2 - Content contains "logged in"ok 3 - GET > http://localhost/set_session_variable/logged/inok 4 - Content > contains "session variable set"ok 5 - GET > http://localhost/get_session_variable/loggednot ok 6 - Content > contains "VAR_logged=n.a." # Failed test 'Content contains > "VAR_logged=n.a."'# at t/live_verify_address.t line 41.# > searched: "VAR_logged=in"# can't find: "VAR_logged=n.a."# > LCSS: "VAR_logged="# LCSS context: "VAR_logged=in"[debug] > 127.0.0.1ok 7 - GET http://localhost/login_without_addressok 8 - > Content contains "logged in (without address)"ok 9 - GET > http://localhost/set_session_variable/logged/inok 10 - Content > contains "session variable set"ok 11 - GET > http://localhost/get_session_variable/loggedok 12 - Content > contains "VAR_logged=in"# Looks like you failed 1 test of > 12.Dubious, test returned 1 (wstat 256, 0x100)Failed 1/12 subtests
From: mail [...] andreasvoegele.com
Download (untitled) / with headers
text/plain 611b
On Thu Sep 22 06:46:05 2011, KENTNL wrote: Show quoted text
> My suspicion is that $ENV{REMOTE_ADDRESS} is being ignored and is just > being > mapped to 127.0.0.1.
REMOTE_ADDR is set to 127.0.0.1 by req_to_psgi() in HTTP::Message::PSGI, which is called by test_psgi() in Plack::Test::MockHTTP. If Plack::Test::MockHTTP is modified to put $ENV{REMOTE_ADDR} into the hash returned by to_psgi() test 6 from t/live_verify_address.t succeeds. Example: my $env = $req->to_psgi; $env->{REMOTE_ADDR} = $ENV{REMOTE_ADDR} if exists $ENV{REMOTE_ADDR}; I have yet to find a way to fix this without changing Plack::Test::MockHTTP.
Download (untitled) / with headers
text/plain 1.5k
On Thu Sep 22 06:46:05 2011, KENTNL wrote: Show quoted text
> My suspicion is that $ENV{REMOTE_ADDRESS} is being ignored and is just > being > mapped to 127.0.0.1. > > I hacked up the Root.pm in a few places to report the address and it > does > appear to be doing just that. > > Will keep poking. > > t/live_verify_address.t .....1..12ok 1 - GET http://localhost/loginok > 2 - Content contains "logged in"ok 3 - GET > http://localhost/set_session_variable/logged/inok 4 - Content > contains "session variable set"ok 5 - GET > http://localhost/get_session_variable/loggednot ok 6 - Content > contains "VAR_logged=n.a." # Failed test 'Content contains > "VAR_logged=n.a."'# at t/live_verify_address.t line 41.# > searched: "VAR_logged=in"# can't find: "VAR_logged=n.a."# > LCSS: "VAR_logged="# LCSS context: "VAR_logged=in"[debug] > 127.0.0.1ok 7 - GET http://localhost/login_without_addressok 8 - > Content contains "logged in (without address)"ok 9 - GET > http://localhost/set_session_variable/logged/inok 10 - Content > contains "session variable set"ok 11 - GET > http://localhost/get_session_variable/loggedok 12 - Content > contains "VAR_logged=in"# Looks like you failed 1 test of > 12.Dubious, test returned 1 (wstat 256, 0x100)Failed 1/12 subtests
I sort of combined both previous suggestions and created a branch (people/dhoss/fix-rt- 71142) with this fixed in it. I used Middleware::ForceEnv to change the REMOTE_ADDR variable, and tests now pass. Would love if someone could check this out.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.