I’m definitely looking into this! Thanks for the article!

Or you could just start node give privileges to port 80 to the running user, using something like start-stop-daemon or setuid/setgid. Just because a service account has access to port 80 does not mean it needs sudoer access. For example, this is how a standard repo apache starts up using the apache/httpd user as a non-privileged user who still has access to port 80 due to the way the server was started through upstart.

Seems like the standard course of action, on *nix anyway, is to use a startup script that can access port 80 but do so using an unprivileged, no-login user. This is in keeping with the “default deny” security mechanism of *nix. The way I usually do it is create a user with access to NOTHING (disable shell login, ensure group membership is minimal, only set file/folder ownership over specific subtrees in the file system, etc.), then adding only the required permissions (such as permissions to write log files, any cron jobs running under that user account, etc).

Screwing around with IPTables IMHO just creates something else that can break, and will drive you crazy trying to figure out why ports aren’t answering, particularly if there’s an upstream firewall, such as the one provided by AWS in front of your servers.

Hope that helps.

In my case I’m writing an API with Sails, and I’m trying to wire up an upload node.js server (not written using Sails) on a different port, but somehow server-side redirect port 80 requests to the port that the upload server is on, because I don’t want to have the user hitting multiple ports, particularly ports other than 80 and 443, since many firewalls don’t allow outbound connections to arbitrary ports.

There’s a way to do this with socket.io, by having socket.io listen for connections to the http server:
http://braindrivendevelopment.com/2013/09/24/node-js-how-to-run-express-and-socket-io-on-the-same-port/

I’m trying to do something similar, but without breaking Sails standards. If someone would like to enlighten me, please do.

Haven’t implemented yet, but I can see 3rd solution is a working proof-of-concept. You should be able to implement dynamic routing and config persistence on top of it, so you can modify route tables without restarting the server.

Thanks for your comment – the 3rd solution was the best i could come up with in terms of app-independence. Of course you’ll have to restart the proxy – and you have a point there as this affects all apps availability – but the other apps can still keep running and keep sessions etc.
Plus no other app is involved when one app crashes…
Would a quick restart of the server really affect users of running apps that much – i think sockets are capable of reconnecting in such case, aren’t they?