Bug 5886 - unable to log in to web if username/password authentication enabled
: unable to log in to web if username/password authentication enabled
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 7.0
: PC Ubuntu Linux
: P2 major (vote)
: ---
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks: 4795
  Show dependency treegraph
 
Reported: 2007-10-22 19:54 UTC by Peter Watkins
Modified: 2008-12-18 11:12 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Watkins 2007-10-22 19:54:14 UTC
If I set a uername & password and enable password protection, I am unable to log in to the web UI. On my system, the password is stored cleartext, and this cause HTTP Basic auth to fail. I think this is a basic ||/&& reversal. With the current code, if the stored password is cleartext, SC7 only accepts user-supplied password if the stored password is empty. I think the intended logic was to accept the user-supplied password if it matches the stored value *or* if the stored value is an empty string (e.g., an empty string in the server prefs means we don't care what the user enters). Perhaps I'm only running into this because my system doesn't have a working crypt() module, but anyway, it's broken.

Suggested patch:

Index: Slim/Web/HTTP.pm
===================================================================
--- Slim/Web/HTTP.pm    (revision 14028)
+++ Slim/Web/HTTP.pm    (working copy)
@@ -2491,8 +2491,11 @@

                my $pwd  = $prefs->get('password');

-               if ($pwd eq $password && $pwd eq '') {
+               # if they supplied what we have stored *or* we have a blank password stored
+               if ( ($pwd eq $password) || ($pwd eq '') ) {

+                       # BUG: we should check if $pwd appears to be crypted
+                       # and, if so, leave $ok at 0 (require the user to supply cleartext)
                        $ok = 1;

                } else {
Comment 1 Chris Owens 2007-10-23 09:14:51 UTC
qa to confirm
Comment 2 KDF 2007-10-23 21:58:59 UTC
I've been looking into this (new bug was also filed at bug 5894 about this same basic thing).
The password encryption was not carried over in the settings conversion.  The point of the test above is that we don't deal with crypt if the password is defined and blank.  If the password is defined as anything but blank, then we want to decrypt and compare.  Change 14054 should fix this.  Passwords will need to be reset in order to properly encrypt.
Comment 3 Chris Owens 2007-10-24 08:10:55 UTC
Peter you should feel free to verify whether or not the change KDF mentions fixes the problem.  Otherwise we'll look into it further.
Comment 4 KDF 2007-10-24 19:47:46 UTC
it was change 14067 that ended up landing on trunk.
Let me know what you think, Peter.  Hopefully it clears up the reasoning for the check against the empty string
Ross, not sure how this links to bug 4795 unles it's only happening when you have password auth required.
Comment 5 Ross Levine 2007-10-26 15:29:10 UTC
Thank you KDF this works great. (SC7, 14113 Ubuntu 7.10)
Comment 6 James Richardson 2008-05-15 13:04:57 UTC
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html