Does it make sense to have Phoenix default to http?

After struggling to understand how to force_ssl via redirection on my application for local development I had the epiphany.

Why do I care about forcing https via request redirection on local development? Which lead me to think, wait why is http the default request protocol for phoenix? Isn’t using http the minority use case now for production, If so why isn’t that true for local development?

One could argue, "why not just disable http for local development if you want to force https" which I think is a valid solution to this issue and may require less effort overall. After all we typically have to specify the port explicitly so you almost always say the full url when working locally.

Beyond that I find setting up the local certs to be a better practice since its going to be a closer representation of my production env and can help me quickly identify requests in my application that are not secure. So then why is it that everyone is still having to reconfigure the default from http to https? Why isn’t https the default for development and what do you think that should or not look like?

1 Like

I personally serve SSL on my load balancer and run HTTP internally. None of my servers expose any port over the internet though, it’s all to the load balancer only.

I’m not sure what’s common in the community and am also curious as to what others do.

5 Likes

So you dont use https locally at all while in development? If so why not?

Why should we? Plain HTTP is easier to set up, does not require a certificate and usually just works…

Developing on HTTPS makes it troublesome to set everything up, as you already have noticed, while it doesn’t change anything else. Your application will work the same either it gets hit by HTTP or HTTPS requests.

And similar to @sb8244 does, usually I do only do HTTP internally and let the LB do the encrypted communication with the client, while all internal communication (at least if it happens in a trusted (virtual) network) happens in HTTP to safe some CPU cycles on both ends…

2 Likes

I don’t fully agree with this. Sure the redirection thing I tried this morning frustrated me I will give you that. Beyond that, I find running mix phx.gen.cert simple enough and following the docs does get me close enough with little effort and pain. The only other obstacle is how the browser handles the requests for localhost while in development but I feel most people figure that out fairly quickly. Also as I stated before I do believe there are some benefits to running https locally. Such as finding requests that are not secure or just the maybe its better to become familiar with ssl in a local evn vs doing it on production. IDK but I’d rather try https locally for development rather than not.

1 Like

I also offload SSL before hitting the Phoenix app. Probably not a lot to add on top of the existing points, more just to add another voice to that model.

Something else I had not noted was I want to start to explore http2 which from what I understand will require this and has issues working on nginx via upstream proxy.

There may be use cases, but I don’t see how this is one of them. If your load balancer is configured to force HTTPS and present them to your app via HTTP then all your requests have to be secure and your apps behaviour has nothing to do with it, it is down to testing your infrastructure is set up correctly not your app.

HTTP2 by itself does not require encryption, its just that the browsers made it a requirement. You can safely use curl with HTTP2 and without encryption, it’ll work.

Also I use traefik as a LB, it terminates HTTP and HTTP2, and does the HTTP->HTTPS redirection for me, it will renew the lets encrypt certificates if necessary and is even able to talk HTTP2 unencrypted with the backend application if I enable it.

And all of this with very little configuration. Configuration that should be done by the Ops team, and not by the Devs.

Testing HTTPS locally does give you nothing, as you know nothing about how the production will look like…

3 Likes

I was just speaking from this experience The hard 3 day lesson I learned trying to use http2 with Phoenix, Cowboy and Nginx

Maybe you know a way that works.

I guess I better hire an opts team then.

Sorry I wasn’t speaking directly to the HTTP2 point more the rouge unsecured route one. I don’t have experience setting this up with HTTP2 which is one of the reasons why i said that there may be use cases.

Ok I guess I was wrong, except I’m not using curl for development I’m working in a browser that does require it…

Well, if you are both in omniperson, then try at least to separate both concerns mentally, thats what I usually do.

I code locally, and when I deploy, I concentrate on the deployment not on stuff that happened locally.

For the deplyoment I have to use an LB anyway, as I have many services of different languages behind the same “domain”, and I need to dispatch them by request path.

This is and was very easy with traefik so far, especially as it does everything for me and as it can reverse-proxy HTTP2 and even does accept HTTP2 on the frontend while talking HTTP on the backend and vice versa.

2 Likes

That’s good to know as I’ve learned nginx still cant by itself. (or maybe it can now, I haven’t checked lately)

And maybe I’m completely wrong about all this and everyone is behind a LB for prod and no one really cares about local https because they never have to deal with https.

Would you say traefik with its file configuration is a good option for someone who isn’t using containers or interested in auto discovery? (Not counting those out for the future.)

1 Like

Lots of other comments since my post. I forgot to mention that I do use https locally so that we don’t mix protocols with chrome. I don’t use local orchestration right now, so I do use Phoenix https with self signed certs.

3 Likes

I prefer this as well

It worked pretty well for me, though I have to admit, I have not yet made the step from 1.7 to 2.0, as too much changes and I still didn’t manage to convert my config…