Support HTTPS

[jzaefferer]

Is there any reason for this system to implement SSL or similar directly? Seems best to leave that to Apache or nginx running in front of this.

[scottgonzalez]

You want to run a web server in front of the node web server to translate from HTTPS to HTTP? I'm not sure how that would work, or what the security implications would be. I'd think you'd want to be able to do a straight pass-thru and not change protocols. But I'd love to hear from someone who actually knows about setting up proxies.

[jzaefferer]

That's a pretty regular setup. I've done this with Apache in front of Tomcat and SoundCloud has their SSL-endpoints in front of their Rails apps. In the context of the jQuery infrastructure, I'd almost bet that we do this with nginx in front of WordPress, but I have to verify that.

That said, if Express or whatever this uses makes SSL easy enough to implement, go for it.

[scottgonzalez]

Ok, that's good to know. I haven't looked into whether Express supports this. If it does, I think we should implement it. If it doesn't, I think we should at least document the basics of how to handle the proxying, but I'd like to link to some other site for actual details with different servers if it's more than a page of information.

[jzaefferer]

@ryanneufeld or @gnarf probably have more first-hand experience with this.

[gnarf]

nginx with ssl in front of a node plain http server works just fine!

SSL support can be in the nginx/apache config for sure.

[scottgonzalez]

Thanks. I'll leave this open until I investigate HTTPS with Express.

[Krinkle]

Something to look out for (we've dealt with this at Wikimedia as well), be sure to output links in HTML always relatively where possible to make sure that people coming in from HTTPS aren't sent to HTTP again (regardless of whether that redirects back to HTTPS or not), and also to ensure you can consistently cache the html output between http and https users (if you want to).

The app configuration should also have a canonical server name setting (e.g. https://example.org) to use for self-reflection. E.g. for usage in a data API (e.g. { id: 1, name: 'Krinkle', viewUrl: 'http://example.org/user/Krinkle' } , e-mail notifications (you don't want mails to contain http or https urls depending on the user who triggered the notification), canonical url in html head, and any server-side processes (e.g. job queue processing things, purging cache, or self-reflecting http requests for something).

[scottgonzalez]

Express actually handles this pretty nicely. The Express app itself is a function which can be passed to https.createServer(), so this can be purely a documentation issue. However, @Krinkle provides a lot of good reasons to have the user provide a canonical server name and handle this internally. It also addresses another issue I've been looking into which is how to support hosting a DEBT instance in a subdirectory instead of at the root.

There doesn't seem to be too much documentation on this, but I figured out that you can mount an Express app as middleware of another Express app and have the sub-app completely ignore the path:

var app1 = express();
app1.get( "/foo", function( request, response ) {
    response.send( "hello" );
});

var app2 = express();
express.use( "/some/deep/directory", app1 );

And now the route from app1 will be mounted at /some/deep/directory/foo. While this is slightly awkward to document, it's also only a partial solution since the first app doesn't know what the mount point is, so functions outside of Express won't be able to generate proper URLs. Having a setting for the root would solve both problems.