agree, there is no need for this as I have TLS termination at my reverse proxy and this mess up my whole setup

Hello, I would like to echo the request to revert this change. I was very surprised to upgrade my controller to see my system broke and that the reason was a "bug fix" that makes it so a still existing settings option is now totally ignored and non-functional. Is this a an internal misalignment issue potentially? The settings menu still shows the setting to disable Redirect HTTP to HTTPs, so I would imagine this is an accidental regression and not a socialized change in direction?

 

Regardless, being able to selfhost without fear of the vendor changing rules or trying to aggressively push their cloud manager is the reason I choose TPLink over brands like Ubiquity. Being able to do my own SSL termination is essential to this.

 

Thank you for your help.

And just to add more information. I work at a goverment agency in my country, and we also do not use any softwares own https services. We consolidate everything and use F5 to handle every softwares https termination and ssl certificates. Or we use API gateways to consolidate api requests from all software. No one in our agency, handles ssl in their own software, since it is inefficient. So with this move, you would be making everyone move away from TP-Link, since no agency wants to handle multiple different softwares ssl termination, in the software, its an update nigthmare to handle. So again, please revert this change. If you wish to help everyone, a better modification would be to be able to add and update certs via scripting and manual config. Which would make automating cert add+updating possible. But even then, those who have central management to handle these, k8s, cert manager, traefik, caddy, npm, f5, and a lot more. Want a way to centrally handle everything.

@Vincent-TP

 

I agree with everything you said if you are referring to internet facing applications.

 

However, many of us run the controller on a local only environment and, in this case, it makes no sense whatsoever to enforce https.

 

Even in the case that you expose your controller to the internet, the typical use case involves a reverse proxy handling the https communication with the outside while the application itself is still only available for local access. It also makes no sense for the app to use https in this case.

 

At least provide an option in the controller to toggle this feature like you already do for the portal.

  @Vincent-TP 
 

I also agree, that yes, HTTPS is the one you need. That is why i'm using Traefik, and cert-manager to handle all my SSL-certificates. But again, you are forcing people to use HTTPS, and you are actually forcing people to use insecure-https, since the certificate omada generates, is self-signed, it is not trusted unless you allow it. So in fact, this is bad security since you are making people trust insecure-certificates.

 

 

And again, as anyone with proper management of certificates, does not handle them in-app, but manages them in other ways. And again, you do not even offer ways to update certificates via cli, or similar ways, so that we could inject our own certificates inside the application. This means that depending on the way we update and use certificates, we would need to manually start updating them.

 

So youre making everyones lives worse, with this change.
* People need to trust self-signed certificates, which are not infact, secure, and cause people to accept what ever certificates, since let's faceit, people do not understand what it means to have self-signed certificate. And those that do understand, will not use it but use their own.
* People who have certification management, outside of the app, are left in the dust, as they need to start manually updating certificates in app, uploading them and setting reminders, instead of automating certificate updates.
* You do not offer anykind of a way, to update certificates automatically, so that people who do have certificate-management in their software, k8s-kluster, could inject the certificates in the application on deployment via initcontainer or similar mechanism.
* And those who have centrally managed gateways, traefik, npm, caddy, which handles ssl-termination, actually have to make their servers more insecure, since they now need to implement a way to trust insecure (ie. self-signed) certificates in the case of omada.

So all in all, again, it should be that people can use http, if they so wish, and people who wish to use your software, and upload certificates there, can use the https. But again, i'm now forced to update my traefik, to be more insecure, by accepting insecure https certificates due to this change.