Bugzilla – Bug 5894
settings -> password doesn't work
Last modified: 2008-12-18 11:12:53 UTC
SqueezeCenter 7 nightly from 10/23 the password function does not work. To reproduce, go to settings -> security -> enable a password and enter any user name and password, then save the settings and try to login to the web interface, it doesn't work.
Thanks Anoop for testing this on a Mac, apparently this is not PC specific.
see bug 5886 and/or bug 5887. check crypt module installation. module dependancies have changed recently. andy has been working on getting them all back to working.
hrm...looks more like the password pref isn't getting validated properly any more. committed a fix at change 14054 that should do the trick. Please reopen if you have any trouble with it.
Verified to be fixed in 10/25 nightly (SC 7, 14113) Thanks KDF.
Setting the password via Web-interface wasn't working for me. Kdf released a patch in SC7 - 14576. With Logging -> prefs = DEBUG, no message in server.log appears. The right pref is used, cause (re)setting username works fine (correctly saved in the pref). SqueezeCenter Version: 7.0 - 14576 - Linux - EN - iso-8859-1 Perl Version: 5.8.8 i486-linux-thread-multi MySQL Version: 5.0.37 Platform Architecture: i686-linux request for reopening. -Ray
ross, would it be possible for you to recheck this. I cannot reproduce the problem. both linux and winxp are working for me, Default and Fishbone skin.
Works fine for 7.0 - 14627 on Ubuntu. Ray exactly what problem did you see?
(In reply to comment #7) > Works fine for 7.0 - 14627 on Ubuntu. Ray exactly what problem did you see? > Version SC7.0 - 14576 is running and setting up a password is still not possible. My server.pref contains password: '' From the web-interface Settings -> Advanced -> Security I have entered a username and password. After pressing the Apply button, no error appears in the console, but the password is not written in the server.pref (password remains ''). Relogin does not require a password, in other words the password has not been set. Regards, Ray
Ray - did you enable the password protection at all? Entering username/password is not enough, you'll have to enable the protection in the field above the username, too. Just checked with 14656 and I was asked about credentials immediately after hitting the save button.
(In reply to comment #9) > Ray - did you enable the password protection at all? Entering username/password > is not enough, you'll have to enable the protection in the field above the > username, too. > > Just checked with 14656 and I was asked about credentials immediately after > hitting the save button. > Well yes I enabled the protection. The credentials show up, but the saved (encrypted) password has not been stored in the server.pref (left empty). So when I enter the username without password in the credentials then access is given.
Ah, ok, I assume you didn't retype the password when you enabled the protection? Then I assume you stored an empty password. We'll have to fix this behaviour.
To make sure that you understand what I did and what goes wrong: Initialy: 1. no password is set in the server.pref 2. protection is enabled Via web-interface: 3. protection unchanged (enabled) 4. username is filed 5. password is filled 6. Clicking <Save> button 7. After Saving the webpage is automatically refreshed, where the *'s in password field are removed. 8. Checking the server.pref, no password is set (left empty). 9. When logging out and back in no password is required, only the username is required. note 1: access rights to the server.pref are OK, cause setting a new username is saved succesfully. note 2: changing the protection enabled -> disabled -> enabled, does not give any change to the save process of the password. If other details are needed, don't hesitate to ask. -Ray
Wow, that's odd. After having tested successfully on Windows & OSX, I've now installed SC7 on Ubuntu 7.04 - and I'm now seeing this issue. Has Ubuntu some limitation when it comes to encryption?
(In reply to comment #13) > Wow, that's odd. After having tested successfully on Windows & OSX, I've now > installed SC7 on Ubuntu 7.04 - and I'm now seeing this issue. Has Ubuntu some > limitation when it comes to encryption? > So you have the same issue on Ubuntu? If it is any helpfull, I am using linux Slackware 12. Working with the stable Slimserver 6.5 and it's night builds, saving a password is working fine.
Change 14666 - crypt() on Linux wouldn't return a valid value with empty salt
(In reply to comment #15) > Change 14666 - crypt() on Linux wouldn't return a valid value with empty salt > Ok what can I do to test it?
Update your subversion repository, wait for the next nightly build or replace Slim::Web::Settings::Server::Security.pm with the latest version from the repository (http://svn.slimdevices.com/*checkout*/trunk/server/Slim/Web/Settings/Server/Security.pm?rev=14666)
(In reply to comment #17) > Update your subversion repository, wait for the next nightly build or replace > Slim::Web::Settings::Server::Security.pm with the latest version from the > repository > (http://svn.slimdevices.com/*checkout*/trunk/server/Slim/Web/Settings/Server/Security.pm?rev=14666) > Ok, I'll come back to yopu with the results within a couple of hours.
Michael, changes to Security.pm are succesfull! Now setting a password for SC 7.0 on linux works fine. The password is encrypted and saved in the server.pref. To login the password is required. Good job. -Ray
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.