Mailing List Archive

* Jesse Sheidlower <jester@panix.com> [2012-12-25 18:50]:
> Right now my solution is to do nothing on my production machine (on
> which I never run the dev server) and to comment things out in
> RequireSSL.pm on my laptop (on which I can then _only_ run the dev
> server), but what should we do about this in general?

What exactly is your requirement?

I extracted Plack::Middleware::RedirectSSL just the other day from the
$work code base and released it to the CPAN tonight. Will that fit your
bill?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Dec 26, 2012 at 03:19:42AM +0100, Aristotle Pagaltzis wrote:
> * Jesse Sheidlower <jester@panix.com> [2012-12-25 18:50]:
> > Right now my solution is to do nothing on my production machine (on
> > which I never run the dev server) and to comment things out in
> > RequireSSL.pm on my laptop (on which I can then _only_ run the dev
> > server), but what should we do about this in general?
>
> What exactly is your requirement?

Same as what's provided by either RequireSSL module--the ability to
easily switch a _particular_ request on to SSL, from a Catalyst
controller. In my case I redirect all login forms to SSL, and all
view-user pages.

> I extracted Plack::Middleware::RedirectSSL just the other day from the
> $work code base and released it to the CPAN tonight. Will that fit your
> bill?

Not sure--I don't use Plack directly and can't quickly learn enough
about it to see--but it seems to me that this will just change _all_
requests to one scheme or another. What I need, and what I'd imagine
most people would want, is the ability to handle this in a Catalyst
controller, on an as-needed basis.

But apart from my needs--and I can always just check the requests
manually and redirect them myself, but there are some quirks that are
the reason for having a module do this for me--there is the overall
problem that the two RequireSSL modules are broken under 5.9x. And
that's why I sent this to the dev list. If
Plack::Middleware::RedirectSSL does (or can be made to do) what I want,
we still need to rewrite or deprecate C::P::RequireSSL and
C::AR::RequireSSL. (And perhaps add a bit to the Cookbook about this
solution. I volunteer, if this is (or can be made to be) the solution.)

Jesse

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

* Jesse Sheidlower <jester@panix.com> [2012-12-26 15:45]:
> On Wed, Dec 26, 2012 at 03:19:42AM +0100, Aristotle Pagaltzis wrote:
> > I extracted Plack::Middleware::RedirectSSL just the other day from
> > the $work code base and released it to the CPAN tonight. Will that
> > fit your bill?
>
> Not sure--I don't use Plack directly and can't quickly learn enough
> about it to see--but it seems to me that this will just change _all_
> requests to one scheme or another. What I need, and what I'd imagine
> most people would want, is the ability to handle this in a Catalyst
> controller, on an as-needed basis.

It will indeed change all of them. Though if you want to redirect some
part of your URL space only, or only a particular host, etc., you can
always wrap it in Plack::Middleware::Conditional to limit it to those
parts of your app.

If you needs are more dynamic, though – if sometimes you want the same
URL served under SSL and sometimes not –, then doing it at the level of
Catalyst actions is probably going to be easier.

For me that is not the case. I have one host for the main app which is
supposed to run all-HTTPS, a bunch of other hosts that are open to the
general public and are supposed to be HTTP, and some hosts for assets
which are used from both the private and public parts of the app and
must therefore respond to both protocols. So I have 3 different PSGI
apps – one Cat app for the login-only site, one Cat app for the public
sites, and Plack::App::File for the assets – and my two Cat apps are
both wrapped in RedirectSSL middlewares (one of them with ssl=1 and one
with ssl=0), and the entire conglomerate is bound together using
a Plack::App::URLMap that does the host-based dispatching for me.

So for certain shapes of complexity, you can handle those very well at
the PSGI layer – arguably much better than at the Catalyst action level.
(I am a lot happier now than I was before when I was doing all the same
thing (minus asset hosts) entirely within a single Cat app, and had to
go out of my way to twist the Cat dispatcher into it.)

It really depends on what exactly you need to do.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On 26/12/2012, at 4:46 AM, Jesse Sheidlower wrote:

>
> Right now my solution is to do nothing on my production machine (on
> which I never run the dev server) and to comment things out in
> RequireSSL.pm on my laptop (on which I can then _only_ run the dev
> server), but what should we do about this in general?
>

For most purposes I think that Plack is the correct solution. But clearly for your problem it isn't.

So I think checking Catalyst::Engine is the problem here. And there are god reasons why we shouldn't rely the dev server reporting itself as a check, e.g. it can be a legitimate deployment target. Seeing as the usual use case is that developer config and production config is different, patching ActionRole::RequireSSL to disable itself if the disable_ssl config key is present (and documenting it as such) might be the way to go (if in doubt, spell it out).

You can of course do this by putting the module in your app's lib directory tree, and/or you can send a patch to the maintainer.


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev