Support SSL about pow

[danreedy]

node.js and Connect support serving SSL pages. I've forked the project and when I have a spare moment I'm hoping I'll have a chance to dig through the configuration and add SSL support.

For ease of use I think it's best to go with a wildcard certificate for *.dev or *.test. I'm thinking it'd be best to generate this during install.sh and save it to $POW_ROOT/SSL. The OS X command sudo /usr/bin/security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" $POW_ROOT + "SSL/certificate.pem" could be used to trust the certificate.

Those are my initial thoughts on the matter anyway.

[josh]

I really didn't need this feature, I just thought it would be fun to play with node's ssl api.

Good point about the cert issue. I didn't really think about that. Hopefully we can make that setup painless.

[danreedy]

SSL cert generation can be annoying and I'm not certain there would be an easy way to implement it in a manner where you aren't making the user type in their information (including the wildcard for the CN field). I wonder if including a "generic" private.pem and public.pem in the installation would be the wiser move.

I imagine most people wouldn't need this, but for ensuring SSL is functioning it would be a sweet option. Painless SSL? Unimaginable for most...

[joshpuetz]

If Pow doesn't support SSL connections, how do 37signals devs run apps that force SSL connections like Campfire?

[josh]

@danreedy Anyway we can generate one generic cert for everyone?

@joshpuetz Force ssl is disabled in development mode

[ssoroka]

It shouldn't matter if it's one cert for everyone, you can generate certs like @danreedy suggested. Generate a sensible default that works and the user can overwrite them with legit certificates if they have them.

[nathanbertram]

Supporting SSL out of the box would be fantastic.

[danreedy]

There are obvious security concerns if you are sending out a default root certificate that has been trusted as an authority by anyone installing pow. If you can pass defaults while creating the cart it may work and work well.

On Apr 7, 2011, at 4:25 PM, [email protected] wrote:

It shouldn't matter if it's one cert for everyone, you can generate certs like @danreedy has. Generate a sensible default that works and the user can overwrite them with legit certificates if they have them.

Reply to this email directly or view it on GitHub:
#5 (comment)

[markbates]

+1 on the SSL support, it's really the biggest reason why i would need something POW. it would instantly become my default server for development if it supported SSL.

[danreedy]

Did a little leg work and I've created two public gists that are proof of concept for an auto generated self-signed multi domain ssl certificate.

The first gist would theoretically go into install.sh. I currently have everything saving to the same folder but this could be modified to use a POW folder ($POW_HOME/SSL). This file generates the key and the certificate in one pass. The last step requires the sudo command and adds this new cert to the trusted roots keychain.

The Second gist is a example node.js https instance setup to be run in the same folder as the previous gist and serves up the self-signed cert.

Because the last step of the first gist makes the cert trusted, you should not receive any warnings on any .dev domains.

Now it's time to work it into POW.

[edwinmoss]

+1

[mataki]

+1

[workergnome]

This would be really, really helpful.

[orangewise]

+1

[ZenCocoon]

+1

[josh]

@sstephenson This is going to be tricky. We're going to need to extend connect.HTTPSServer too. Somehow we'd need to move the code in pow.HttpServer into a mixin so we can share it between both classes.

[sstephenson]

In that case, we ought to use composition instead of a mixin -- it wouldn't make sense for the HTTPS server to have its own set of Nack workers.

[josh]

Hrm, right, we need to worry about that too. Maybe we need an HttpHandler class.

HttpServer  -\                 /- RackApplication
              |- HttpHandler -| - NodeApplication
HttpsServer -/                 \- ProxyApplication

Does this fit into the EventEmitter emitter stuff you are already working on?

[gvarela]

You can setup an SSL proxy through nginx until it is supported by pow.

Just follow these instructions:

http://www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/

[john-griffin]

+1

[mattvanhorn]

+1

[CodeOfficer]

+1 ... ssl support is the only thing stopping me from using pow.

On a side note, I'd love to hear more about the how and why of disabling ssl in development mode.

[ksylvest]

+1 SSL support would be awesome!

[estoner]

+1

+1 I just began building an ecommerce function and now can't use my POW :-(

[sstephenson]

@blueheadpublishing Sure you can. If you use a middleware or before_filter to force SSL, just skip it when Rails.env is development. That's what we do for all our apps at 37signals.

[CodeOfficer]

@sstephenson that works great for apps that are wholly behind ssl, but not so much for sites that are a mix. I'm sure I'm doing it wrong, but I've always felt more comfortable with using real ssl in dev mode. I don't think I'm alone in that regard, but I'd love to be convinced otherwise.

[josh]

Considering closing this issue. I don't really feel like working on it anymore.

No number of +1s is going to magically produce a working patch.

[gvarela]

If you need SSL that bad just use an Nginx proxy as I linked to above. It takes ten minutes.

http://shiny-bits-of-code.tumblr.com/post/4749553253/ssl-proxy-with-nginx

[sstephenson]

Yep, I'm with @josh on this one -- closing the ticket. If anyone wants to take a shot at implementing SSL, feel free to make a patch and open a pull request.

[jeremyhaile]

Zero-config SSL support (with self signed cert) built-in to pow would save time setting up dev machines and make it easier to get people to adopt pow over other more complicated setups!

[cmer]

+1

[fred]

just use nginx from brew, add this config http://shiny-bits-of-code.tumblr.com/post/4749553253/ssl-proxy-with-nginx
and just edit the line that says server_name

server_name *.dev;

very easy steps:

1. brew install nginx
2. setup vhost file
3. generate selfsigned ssl http://dracoblue.net/dev/https-nginx-with-self-signed-ssl-certificate/188/
   use *.dev as domain and full name when you generate the ssl.
4. start nginx…

[jeremyhaile]

Installing and configuring nginx defeats the entire purpose of using a zero-conf app server. I quit using pow based on how slow bugs were being fixed and because once I had to install and configure nginx to support SSL, I realized it wasn't any harder to just use unicorn or thin than it was to use pow.

[fred]

jeremyhaile, yes true, if you have a few apps.
If you have many apps, let's say, 40+ apps. it make things a lot lot easier, starting unicorn/thin for each app, creating the nginx vhost, reload nginx, setup host file domain.

otherwise in pow only need one command :)

$ ln -s ~/projetos/app43 ~/.pow/

[jugyo]

My solution is here: https://github.com/jugyo/tunnels
This is a proxy to http from https.

[pcasaretto]

👍
would really help now that Facebook requires https

[jeremyhaile]

fred: my point wasn't that pow isn't easier than nginx/unicorn - but rather that if I have to configure ssl with nginx, it isn't that much harder to just run with unicorn at that point. If pow would add ssl support, I could eliminate having to run nginx on my dev machine altogether.

[paulnicholson]

Here is my solution using stud. https://gist.github.com/2050941#file_gistfile1.md

[cmer]

@paulnicholson I just tested this and it works very well. Thanks! I wish 37s would bundle your solution into Pow. I would be fine to have Stud as a dependency for SSL support.

[recurser]

thanks @paulnicholson, works great!

[antoinegrant]

Thanks @paulnicholson your solution is very helpful!

[johnantoni]

thanks @jugyo, tunnels works like a charm though won't daemonize but that's not a problem.

https://github.com/jugyo/tunnels

$ gem install tunnels
$ rvmsudo tunnels

after which all traffic to 443 will pipe over to port 80 where pow's waiting to pick up.

...i did try stud but no go, though prefer the less invasive tunnels solution

[lukesarnacki]

Just in case somebody uses rbenv: https://github.com/dcarley/rbenv-sudo :)

[apsoto]

another option: https://ngrok.com/