Added server.apiProxy.useSsl option to enable HTTP -> HTTPS API proxying#352
Added server.apiProxy.useSsl option to enable HTTP -> HTTPS API proxying#352searls merged 2 commits intolinemanjs:masterfrom
Conversation
…ing. Backward compatible (default is false).
|
Good job navigating the absolutely horrendous server.coffee task. @davemo you've been using lineman lately, would you mind validating this locally? |
There was a problem hiding this comment.
Do we need to make this setting exposed via env var? The WEB_PORT setting is exposed because it's common to want to change that setting on different invocations. SSL, on the other hand, strikes me as something that would be set for the project and then never touched. My vote is to remove the env-var unless we would want to change the SSL setting per invocation (vs per project).
There was a problem hiding this comment.
I added the API_USE_SSL environment variable to be consistent with the API_PORT environment variable. It seems like if you are changing the port, you might need to change whether you are using SSL or not too. However, I don't really see a compelling case for either.
There is a use case where you might change the proxy endpoint (host/port/protocol) from backing dev server to a test server or even production while developing but I would think you would need to either be able to change all of the components or none of them via the environment. Proxy host doesn't have an environment variable so that probably defeats the purpose right there. Personally, I don't use the environment features. If I need to point somewhere else temporarily, I just edit my application.js file and then revert when I'm done.
I'm happy to remove the API_USE_SSL environment variable (and/or update the API host and port to be consistent) and update the pull request if there is consensus.
Let me know what works best for your process and I'll try to follow along.
There was a problem hiding this comment.
If you're not using it, let's nix it in the interest of just making the minimal change
|
This looks fine from a backwards compatibility and sensible default point of view; I haven't tested this locally with any meaningful configuration to see if it actually works -- I'm going to defer judgment on that to @ajwhitney. I'm assuming this has been tested in your local copy of Lineman @ajwhitney to ensure that it's solving your problems and not introducing any regressions? |
…evel configuration override of server.apiProxy.useSsl) per feedback from @jasonkarns and @searls in order to minimize the footprint of the useSsl change.
|
Yes @davemo. I am using this change and it appears to work fine with both HTTP and HTTPS backends. HTTP uses a backward compatible configuration (HTTPS requires the useSsl property, of course). It does not appear to me to be introducing any issues. |
|
I've updated the pull request to not include the API_USE_SSL environment variable |
|
BTW guys, we use Lineman everyday and have been very happy with it. It simply works great for us. Thank you very much for your hard work on it and for sharing it with the rest of us. I know it has taken a lot of time and effort and it is appreciated. |
|
@ajwhitney the quickest way to my merge button is, indeed, flattery. |
Added server.apiProxy.useSsl option to enable HTTP -> HTTPS API proxying
There are environments where back-end services are only available via HTTPS and this enables the use of the very useful Lineman proxy in those environments.
This change includes a configuration point to enable proxying of back-end services via SSL/TLS. This is backward compatible (default is false). You opt-in to SSL by setting server.apiProxy.useSsl = true (and typically sever.apiProxy.port = 443).
Note: if your (intermediate) certs aren't recognized by nodejs (if you encounter the error UNABLE_TO_VERIFY_LEAF_SIGNATURE), you can force enable SSL communication (and assume the security risk) by adding "process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0'" in your application.js.