GNOME Bugzilla – Bug 487203
DAAP password authenication problems when accessing a DAAP server
Last modified: 2010-01-26 00:43:28 UTC
Please describe the problem: I am running a DAAP server (not iTunes), Firefly Media Server v 1671. When I have the DAAP server setup to advertise the Library password protected, Banshee can see the share and it has the lock icon on it. When I try to connect to it, I DON'T get prompted for the password. If I set up the Firefly Server without password authenication and have Banshee try to connect, Banshee PROMPTS me for a password, in which case I leave the password field blank, press enter and I can connect to the share. The problem seems to reside in that Banshee won't prompt me to enter the share password when a share password exists. Steps to reproduce: 1. The problem is reproduced when trying to connect to a password protected DAAP server 2. 3. Actual results: You never get prompted to enter the password and get this error: - The provided login credentials are invalid - The login process was canceled - Too many users are connected to this share - The music share is hosted by iTunes7 End result is that you can not connect to the share. Expected results: I would expect to get prompted to enter the DAAP server share password and have access to see the share. Does this happen every time? Yes Other information: On a Windows PC using Itunes I can connect to the Firefly server with no issues when password authentication is turned on or off.
Some additional info. I installed rhythmbox(0.11.2) on the same box as Banshee is installed, password protected the Music on the Firefly server. Rhythmbox prompted me to enter the share password and I was able to connect to the DAAP share after entering the password.
Created attachment 119567 [details] [review] Use default content codes for password protected servers
Created attachment 119616 [details] [review] Only use default codes for password protected servers, no for net failures
Changing version, as it seems that both the issue and the patch apply to trunk.
Félix, the real fix here would be to authenticate, no? Setting the bag to the Default whenever we connect to a pwd-protected share sounds like a recipe for strange failures down the road.
Well, the code to authenticate is already in banshee :) The problem is that we try to retrieve the content-codes, that are password-protected, before we ask the credentials to the user. Btw, I've seen a forgot attaching a newer version of the patch. It just re-throws the exception if it's other kind of problem, only "bypassing" the authentication troubles.
Well, we should delay getting the content codes until we've authenticated, then.
mmm I think you're right. I'm working on it, will post a patch soon.
Created attachment 126374 [details] [review] Delay retrieval of content-codes until credentials are provided I was trying something far more complicated, until I realized this one-liner works perfectly.
Much better. Can we do it right after the Fetch ("/login") call though? That makes the most sense to me - login, then see what kinda stuff it supports, then get the tracks etc..
It seems iTunes works the other way (see http://www.tapjam.net/daap/ , chapter IV. Client/Server conversation overview). First retrieve server-info, then content-codes, then login. I agree it's weird sending credentials before we are properly logging in, but at least firefly needs them for content-codes (not for server-info, it seems).
I just added the patch posted by Félix Velasco to the source files in the Ubuntu repository for Jaunty (v.1.4.3) and it solved this issue. Thanks, Félix! Brett Ussher
Comment on attachment 126374 [details] [review] Delay retrieval of content-codes until credentials are provided Committed, thanks Felix.