FAQ
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090424/655bd027/attachment.htm

Search Discussions

  • Tomas Doran at Apr 24, 2009 at 9:22 pm

    On 24 Apr 2009, at 22:10, seasprocket@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
  • Phil Mitchell at Apr 24, 2009 at 10:48 pm

    On Fri, Apr 24, 2009 at 2:22 PM, Tomas Doran wrote:
    On 24 Apr 2009, at 22:10, seasprocket@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
    ==========================
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090424/bd3d15c5/attachment.htm
  • Bill Moseley at Apr 25, 2009 at 1:29 pm

    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.
    moseley@hank.org
    Sent from my iMutt
  • Seasprocket at Apr 25, 2009 at 6:13 pm

    On Sat, Apr 25, 2009 at 6:29 AM, Bill Moseley 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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090425/c62b2702/attachment.htm
  • Matt S Trout at Apr 27, 2009 at 11:22 am

    On Sat, Apr 25, 2009 at 11:13:16AM -0700, seasprocket@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 Director http://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)
  • Phil Mitchell at Apr 27, 2009 at 11:18 pm

    On Mon, Apr 27, 2009 at 4:22 AM, Matt S Trout wrote:

    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]
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090427/11168e33/attachment.htm
  • Tomas Doran at Apr 28, 2009 at 10:16 am

    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
  • Hans Dieter Pearcey at Apr 25, 2009 at 8:23 pm

    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.
  • Bill Moseley at Apr 25, 2009 at 11:13 pm

    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.
    moseley@hank.org
    Sent from my iMutt
  • Tomas Doran at Apr 26, 2009 at 11:48 am

    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
  • Seasprocket at Apr 26, 2009 at 12:46 am

    On Sat, Apr 25, 2009 at 1:23 PM, 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 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?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090425/2fc7f645/attachment.htm
  • Hans Dieter Pearcey at Apr 26, 2009 at 12:55 am

    On Sat, Apr 25, 2009 at 05:46:55PM -0700, seasprocket@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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 24, '09 at 9:10p
activeApr 28, '09 at 10:16a
posts13
users6
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase