On 5/14/21 4:22 PM, Etienne Champetier wrote:
Hi All,Le ven. 14 mai 2021 à 05:00, Petr Štetiar <yn...@true.cz> a écrit :Fernando Frediani <fhfredi...@gmail.com> [2021-05-11 20:13:18]: Hi,I am no sure https support should still be something by default in the images as it's not something really essentialto me it's like discussion about telnet versus SSH. (Puting aside, that oneshouldn't be using password at all) If it's fine with you to send your
root
password over telnet, then SSH is not essential, I agree. FYI HTTPS wouldn't be enabled by default, it would be *available* by default, giving users of default release images choice for management of their devices over HTTPS, by doing so *explicitly*.I'm all for HTTPS to be shipped by default One painfull "bug" that some people might face having both HTTP and HTTPS, when you login using HTTPS, the sysauth cookie has secure=true, so you can't login via HTTP anymore because it's trying to modify the secure=true sysauth cookie :( Etienne
I ran into this when I first used an image with luci-ssl and then changed to one without it. What about setting a not secure cookie that tells the browser that https was used when we access LuCI over https. When the browser accesses LuCI now over unencrypted http the code will check for this cookie and forward the browser to the https version. If this cookie is not found it behaves like before. If https worked once it will probably also work a second time.
Is it even possible to handle the error when we want to overwrite the secure=true cookie and do a forward to https instead?
Hauke
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
