10-19-2020, 11:46 AM
(10-19-2020, 09:12 AM)metapy Wrote: The password is not very secure in the first place. It would not withstand someone using wireshark as you mentioned already.
Code:Note that the password option is not secure: passwords are sent in clear-text over the connection, and the client cannot verify the server’s identity.
It should just be music being played, would someone go through the trouble of changing it without permission? If someone connected and changed the music could you not just talk to them?
If Tim didn't want to add the feature you could always hire it out it is GPL 3 licensed. If the code was any good Tim might even add it to the mainline code base as well to make updates easier.
For password input with basic_auth i use HTTPS and a self signed certificate. Port 80 was redirect to 443 over nginx and secure with my ssl certificate. For normale use its enough protection. User inputs like passwords over basic_auth are secured through HTTPS and can not capture in plain-text with wireshark. At now it works ok, iOS only sometimes wants my access data a second time. But thats okay.
Of course you are right with "it should just be music played", but i want prevent this situation with a password protected webgui. When the company is big there are always some jokers...
I think Tim would adapt the code if there were a lot of requests for it. But unfortunately there is not enough demand for this...
