Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
Phil Mitchell wrote: For (a) documentation, I took a stab at writing some. If this looks okay, I'll submit a patch ... Heh, unified diffs are easier to read (at least to me) than scanning for [ADDED]. That said, this looks good, please submit said patch :) Thank you! t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 11:13:16AM -0700, seasproc...@gmail.com wrote: Yes, it all makes sense ... now. Still, I think that when something as fundamental as $c-request-base is fragile, it calls for some thought. Perhaps a config variable that lets you set your SSL port? My guess is that the average cat user does not realize that req-secure and req-base may be unreliable. I'm not sure unreliable is the right word. Determined by heuristics is probably more accurate. I think either (a) we need more documentation explaining exactly how it makes its best guess so that it's more obvious to the people the guess is wrong for what's happening, or (b) we need (a) and some better guessing. Let's keep discussing how it could/should have guessed for your setup to find out which :) -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue: Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Any questions? Mail mst at shadowcat.co.uk My blog: http://www.shadowcat.co.uk/blog/matt-s-trout/ (warning: profanity) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Mon, Apr 27, 2009 at 4:22 AM, Matt S Trout dbix-cl...@trout.me.ukwrote: I think either (a) we need more documentation explaining exactly how it makes its best guess so that it's more obvious to the people the guess is wrong for what's happening, or (b) we need (a) and some better guessing. Let's keep discussing how it could/should have guessed for your setup to find out which :) For (b), I really don't know what could have been done for my setup -- non-standard port and (apparently) no env variable being set for HTTPS. Fyi, the reason for the non-standard port is that I'm running both a dev and a prod system on the same box using virtual hosts. For (a) documentation, I took a stab at writing some. If this looks okay, I'll submit a patch ... UPDATED DOCS $req-base Contains the URI base. This will always have a trailing slash. [ADDED:] Note that the URI scheme (eg., http vs. https) must be determined through heuristics; depending on your server configuration, it may be incorrect. See $req-secure for more info.[END] If your application was queried with the URI http://localhost:3000/some/paththen base is http://localhost:3000/. $req-secure Returns true or false, indicating whether the connection is secure (https). [ADDED] Note that the URI scheme (eg., http vs. https) must be determined through heuristics, and therefore the reliablity of $req-secure will depend on your server configuration. If you are serving secure pages on the standard SSL port (443) and/or setting the HTTPS environment variable, $req-secure should be valid. [END] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On 26 Apr 2009, at 00:13, Bill Moseley wrote: On Sat, Apr 25, 2009 at 04:23:50PM -0400, Hans Dieter Pearcey wrote: On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote: The SSL decryption is happening on Apache and Apache is proxying the request to Catalyst. What? No it isn't. It's using mod_perl; there's no reverse proxying going on from the config snippet paste. Indeed, my mistake -- I assumed a front-end proxy when the original post mentioned running on a non-standard port. It didn't even cross my mind that Catalyst wouldn't be behind a proxy or load balancer. That said, I think that what you originally described would be terribly useful - although I think it'd be better implemented as a request class role than as a plugin. I vote for the headers being: X-Is-SSL: X-Catalyst-Request-Base: being the request headers, but I'm open to suggestions. Would anyone like to volunteer to work on this? It'd be fairly easy and _really really_ useful for a whole range of people, I for one promise to send patches ;)... Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Fri, Apr 24, 2009 at 03:48:36PM -0700, Phil Mitchell wrote:
I am running mod_perl/Apache 2.0 and serving SSL on a non-standard port via
a VirtualHost. I thought my apache setup was vanilla, but perhaps not -- I
am no apache expert. It seems surprising to have to set an ENV variable in
order for $c-request-base to work correctly...
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst. Catalyst has no way to know that the request was
originally SSL. AFAIK, there's no standard way a front end proxy
can indicate the initial request was SSL to the back end that works
with all proxies.
Therefore, you need to make up some way that Catalyst will know the
connection is secure from something in the request -- such as a header
or the port that the connection is coming in on.
In my case I have a plugin where prepare_headers() looks at a number
of things to determine if it's SSL.
On Apache front end I use separate ports for SSL and non-SSL traffic
and use simple matching, and with Perlbal I set a header:
# Check if running under Perlbal
if ( $req-header( 'X-Perlbal' ) ) {
# Unlike mod_perl, Perlbal passes Host: unchanged.
# Engine::Apache uses X-Forwarded-Host, so copy
# Host to X-Forwarded-Host.
$req-header( 'X-Forwarded-Host' = $req-header( 'Host' ) );
$req-secure( 1 ) if $req-header( 'X-Ssl' );
return;
}
# Determine if we are in SSL mode using crude match
$req-secure( 1 ) if $req-header( 'Host' ) =~ /:\d*443$/;
return;
--
Bill Moseley.
mose...@hank.org
Sent from my iMutt
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 6:29 AM, Bill Moseley mose...@hank.org wrote: On Fri, Apr 24, 2009 at 03:48:36PM -0700, Phil Mitchell wrote: I am running mod_perl/Apache 2.0 and serving SSL on a non-standard port via a VirtualHost. I thought my apache setup was vanilla, but perhaps not -- I am no apache expert. It seems surprising to have to set an ENV variable in order for $c-request-base to work correctly... The SSL decryption is happening on Apache and Apache is proxying the request to Catalyst. Catalyst has no way to know that the request was originally SSL. AFAIK, there's no standard way a front end proxy can indicate the initial request was SSL to the back end that works with all proxies. Yes, it all makes sense ... now. Still, I think that when something as fundamental as $c-request-base is fragile, it calls for some thought. Perhaps a config variable that lets you set your SSL port? My guess is that the average cat user does not realize that req-secure and req-base may be unreliable. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't. It's using mod_perl; there's no reverse proxying going on
from the config snippet pasted.
Also, this means that Engine::CGI is a red herring.
Dear original poster: is Apache2::ModSSL installed?
Here's the relevant code from Engine::Apache:
if ($INC{'Apache2/ModSSL.pm'}) {
$c-request-secure(1) if $self-apache-connection-is_https;
} else {
my $https = $self-apache-subprocess_env('HTTPS');
$c-request-secure(1) if defined $https and uc $https eq 'ON';
}
The port should have nothing to do with it.
hdp.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 04:23:50PM -0400, Hans Dieter Pearcey wrote:
On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote:
The SSL decryption is happening on Apache and Apache is proxying the
request to Catalyst.
What? No it isn't. It's using mod_perl; there's no reverse proxying going on
from the config snippet paste.
Indeed, my mistake -- I assumed a front-end proxy when the original
post mentioned running on a non-standard port. It didn't even cross
my mind that Catalyst wouldn't be behind a proxy or load balancer.
Also, this means that Engine::CGI is a red herring.
Dear original poster: is Apache2::ModSSL installed?
Here's the relevant code from Engine::Apache:
if ($INC{'Apache2/ModSSL.pm'}) {
$c-request-secure(1) if $self-apache-connection-is_https;
} else {
my $https = $self-apache-subprocess_env('HTTPS');
$c-request-secure(1) if defined $https and uc $https eq 'ON';
}
The port should have nothing to do with it.
--
Bill Moseley.
mose...@hank.org
Sent from my iMutt
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 1:23 PM, Hans Dieter Pearcey hdp.perl.catalyst.us...@weftsoar.net wrote: On Sat, Apr 25, 2009 at 06:29:50AM -0700, Bill Moseley wrote: The SSL decryption is happening on Apache and Apache is proxying the request to Catalyst. What? No it isn't. It's using mod_perl; there's no reverse proxying going on from the config snippet pasted. Also, this means that Engine::CGI is a red herring. Dear original poster: is Apache2::ModSSL installed? No, it's not. Should it be? Other than to avoid this issue? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Sat, Apr 25, 2009 at 05:46:55PM -0700, seasproc...@gmail.com wrote: Dear original poster: is Apache2::ModSSL installed? No, it's not. Should it be? Other than to avoid this issue? I have no idea; the code I pasted from Engine::Apache uses it as its preferred method of determining SSL-ness. Try installing it and see if your application correctly detects -secure. hdp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On 24 Apr 2009, at 22:10, seasproc...@gmail.com wrote:
The expected behavior (for me) is that secure() returns true if the
connection is secured via SSL.
Looking at Engine::CGI, it appears that it only returns true if $ENV
{HTTPS} eq 'ON' or if you're on Port 443.
Furthermore, if secure fails because you're on a non-standard port
and HTTPS is not set, then base returns the wrong base (http
instead of https).
I am just really confused or is this desired behavior?
Neither of the above.
It's a bit too simple.
Please illustrate your use case and how the current behavior doesn't
work for you, so we can work out what to do to instead / as well.
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unexpected behavior of $c-request-secure and $c-request-base
On Fri, Apr 24, 2009 at 2:22 PM, Tomas Doran bobtf...@bobtfish.net wrote:
On 24 Apr 2009, at 22:10, seasproc...@gmail.com wrote:
The expected behavior (for me) is that secure() returns true if the
connection is secured via SSL.
Looking at Engine::CGI, it appears that it only returns true if
$ENV{HTTPS} eq 'ON' or if you're on Port 443.
Furthermore, if secure fails because you're on a non-standard port and
HTTPS is not set, then base returns the wrong base (http instead of https).
I am just really confused or is this desired behavior?
Neither of the above.
It's a bit too simple.
Please illustrate your use case and how the current behavior doesn't work
for you, so we can work out what to do to instead / as well.
I am running mod_perl/Apache 2.0 and serving SSL on a non-standard port via
a VirtualHost. I thought my apache setup was vanilla, but perhaps not -- I
am no apache expert. It seems surprising to have to set an ENV variable in
order for $c-request-base to work correctly...
cheers,.
Phil
If it's useful, here's my setup:
VirtualHost xx.xx.xx.xxx:444
SSLEngine on
ServerName dev.myserver.org
DocumentRoot /web/myroot
Redirect /pub http://dev.myserver.org:8080/pub
# enable SSL:
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile my.crt
SSLCertificateKeyFile my.key
Location /
SetHandler modperl
PerlResponseHandler BCDB
/Location
LocationMatch (/static|favicon.ico)
SetHandler default-handler
/LocationMatch
/VirtualHost
--
==
2People citizen's network for climate action: http://www.2people.org
Greater Seattle Climate Dialogues: http://www.climatedialogues.org
The Great Warming coalition
==
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
