After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 418316 - Totem does not use HTTP Authentication information from Keyring
Totem does not use HTTP Authentication information from Keyring
Status: RESOLVED FIXED
Product: totem
Classification: Core
Component: xine-lib backend
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Maintainer alias for xine-lib component of Totem
Maintainer alias for xine-lib component of Totem
Depends on:
Blocks:
 
 
Reported: 2007-03-14 18:27 UTC by Dmitri Fedortchenko
Modified: 2007-08-26 00:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Patch to add username/password from keyring to an URL before passing it to xine-lib (3.05 KB, patch)
2007-04-17 00:16 UTC, Dmitri Fedortchenko
none Details | Review
Improved patch to add username/password from keyring to an URL before passing it to xine-lib (2.96 KB, patch)
2007-04-17 12:58 UTC, Dmitri Fedortchenko
needs-work Details | Review
patch to add username/password from keyring to an URL before passing it to xine-lib (2.97 KB, patch)
2007-05-11 14:35 UTC, Dmitri Fedortchenko
none Details | Review
patch to add username/password from keyring to an URL before passing it to xine-lib (2.97 KB, patch)
2007-05-11 14:41 UTC, Dmitri Fedortchenko
none Details | Review
patch to add username/password from keyring to an URL before passing it to xine-lib (3.62 KB, patch)
2007-05-18 15:44 UTC, Dmitri Fedortchenko
reviewed Details | Review
patch to add username/password from keyring to an URL before passing it to xine-lib (4.32 KB, patch)
2007-07-14 09:43 UTC, Dmitri Fedortchenko
none Details | Review

Description Dmitri Fedortchenko 2007-03-14 18:27:30 UTC
Please describe the problem:
Totem does not look up authorization information in gnome keyring when trying to place a file that is protected by basic HTTP authentication. Please note that totem SAVES this data to the keyring, but then forgets to read it.

This applies to totem-xine because totem-gstreamer can not play remote file at all. However since it is related to gnome-keyring, I believe it is a totem issue.
-----------
When you try to stream a file from an HTTP server that requires authentication, totem asks you nicely for a username and password, which you can also then save to the Keyring (a checkbox is available).

So far so good. However, after you click OK, you get the following message: "The connection to the server is refused."

This happens every time you subsequently try to play the same file.
The auth information is correct, and if you delete the entry from the Keyring, then you once again get the same dialog box and the circle starts again.


Steps to reproduce:
1. CTRL-L - Paste the URL of a file on a server which requires basic HTTP authentication
2. Enter the required data
3. Get error message
4. Try to play the same file again: The Connection to the server is refused
5. Repeat step 4 as many times as you want.
6. Delete entry from Keyring, go to step 1.


Actual results:
Output of %totem --debug:

libsputext: spu_src_encoding = utf-8
xine: found input plugin  : http input plugin
input_http: http status not 2xx: >401 Authorization Required<
xine: input plugin cannot open MRL [http://server.com/file.avi]

net_buf_ctrl: nbc_close

net_buf_ctrl: nbc_close: done
xine: cannot find input plugin for MRL [http://server.com/file.avi]



Expected results:
Totem should look up the auth information in the keyring if a 401 error is encountered.

Does this happen every time?
Yes

Other information:
Comment 1 Dmitri Fedortchenko 2007-03-14 19:07:58 UTC
It seems I was mistaken!

I had confused totem-gstreamer with totem-xine.
Gstreamer actually asked for password, totem-xine never asked for password.
I forgot that I replaced -gstreamer with -xine at some point, and only discovered it after I posted the bug.

Ashamed beyond words, am I.

However, the authentication problem still remains, but I guess it's up to xine?
Comment 2 Bastien Nocera 2007-03-14 19:26:55 UTC
xine-lib has no support for authentication, unfortunately. Feel free to request it.
Comment 3 Dmitri Fedortchenko 2007-04-16 11:45:48 UTC
(In reply to comment #2)
> xine-lib has no support for authentication, unfortunately. Feel free to request
> it.
> 

Still tinkering with all this ;)

I found something interesting. Maybe you could point me in the right direction?

I just got the latest Totem SVN (REV 4231).
I built it running "./autogen.sh" then "./configure --enable-xine"

Now when I try to play a file from an HTTP location that requires authorization, I actually get a GNOME auth dialog. It does not go away until I enter the correct credentials and it saves stuff into the keyring. (meaning that totem does it's own HTTP auth checks)

However it does not pass the entered data over to xine-lib. Now xine-lib itself actually reports the wrong error message, but I made a patch for it (which I am sending to xine-devel mailing list). Still it seems that totem is certainly doing something with HTTP authentication, it doesnt seem to be all up to xine-lib. (i am latest cvs xine-lib 1.1.5, it still has the same issue as 1.1.2)

Either that, or maybe the way I am building it from SVN source retains some portion of Gstreamer code? (the gstreamer version of totem actually supports HTTP authentication)

I'd love to help out with this.
Comment 4 Dmitri Fedortchenko 2007-04-16 12:23:10 UTC
I found something...

In <code>totem_action_add_recent in totem-menu.c:657</code>, there is a function call to <code>gnome_vfs_get_mime_type()</code>... 

This function call includes the file that we are trying to open. Since gnome-vfs supports http authentication, a dialog is popped up.

So in theory we could manipulate this to our advantage and fetch the HTTP username and password from gnome vfs, modify the uri and send it to xine-lib...

Gonna dig a little more.
Comment 5 Bastien Nocera 2007-04-16 13:19:40 UTC
It will connect using gnome-vfs in the playlist parsing code, and possibly in some other places in the UI. There's still no way to feed the login/password to xine-lib, so it would need to be fixed there.
Comment 6 Dmitri Fedortchenko 2007-04-16 13:26:08 UTC
So there really is no way to fetch the username/password that was entered in the gnome auth dialog?
Comment 7 Bastien Nocera 2007-04-16 13:26:57 UTC
There is, but there's no way to pass it to xine-lib.
Comment 8 Dmitri Fedortchenko 2007-04-16 13:41:53 UTC
Why not just parse it into the URI before sending it to xine-lib?

Like so: http://username:password@uri/foo/bar.avi

(if you type in a uri like the above manually, xine handles it properly)
You can see it here in this code from xine-lib/input/input_http.c:
  if (this->user && strlen(this->user)) {
    snprintf (this->buf + buflen, BUFSIZE - buflen,
              "Authorization: Basic %s\015\012", this->auth);
    buflen = strlen(this->buf);
  }
  
Comment 9 Bastien Nocera 2007-04-16 13:49:17 UTC
(In reply to comment #8)
> Why not just parse it into the URI before sending it to xine-lib?
> 
> Like so: http://username:password@uri/foo/bar.avi

Because it would mean the credentials would get all over Totem, including in parts we don't want this sort of information. Trawl the xine-devel mailing list, there were some patches made for this, but they were never integrated.
Comment 10 Dmitri Fedortchenko 2007-04-16 13:58:31 UTC
Yeah I kinda thought so too...but I was hoping that maybe the credentials could be sent to xine-lib at the "last possible moment" (maybe a wrapper function of sorts so the credentials would not be all over totem at least) and that xine would not actually return the credentials back when reporting errors. Wishful thinking you know :)

Anyway, thanks, I am gonna go look around some more.

If its not too much trouble, do you have any tips on how to fetch the username and password from gnome_vfs? I've been trying to find some information, but it's eluding me.
Comment 11 Bastien Nocera 2007-04-16 14:07:56 UTC
(In reply to comment #10)
> Yeah I kinda thought so too...but I was hoping that maybe the credentials could
> be sent to xine-lib at the "last possible moment" (maybe a wrapper function of
> sorts so the credentials would not be all over totem at least) and that xine
> would not actually return the credentials back when reporting errors. Wishful
> thinking you know :)

Could be done actually, in the xine-lib backend itself.

> Anyway, thanks, I am gonna go look around some more.
> 
> If its not too much trouble, do you have any tips on how to fetch the username
> and password from gnome_vfs? I've been trying to find some information, but
> it's eluding me.

You'd actually get it from the gnome-keyring.

Comment 12 Dmitri Fedortchenko 2007-04-16 20:05:14 UTC
I am working on implementing this functionality, I should have a patch uploaded later tonight (or tomorrow).

However, at the moment it seems that the only way to fetch the user/pass that was entered in the auth dialog, is to force the user to check the "remember password for session" or "store password in keyring" checkboxes... If you just enter the user/pass, it can't be be fetched from the keyring... At least that is what it looks like...
Am I mistaken?
Comment 13 Bastien Nocera 2007-04-16 20:12:54 UTC
(In reply to comment #12)
> I am working on implementing this functionality, I should have a patch uploaded
> later tonight (or tomorrow).
> 
> However, at the moment it seems that the only way to fetch the user/pass that
> was entered in the auth dialog, is to force the user to check the "remember
> password for session" or "store password in keyring" checkboxes... If you just
> enter the user/pass, it can't be be fetched from the keyring... At least that
> is what it looks like...
> Am I mistaken?

It usually remembers the passwords for you until the end of the session...
Comment 14 Dmitri Fedortchenko 2007-04-16 20:28:23 UTC
There are two checkboxes in the auth dialog...
"Remember password for this session" and "Save password in keyring"

Checking the session one stores the password in the "session" keyring. Checking the second one stores the password in the "default" keyring. Not checking either one stores the password somewhere.. until the application quits...

I am using this method to fetch the password: gnome_keyring_find_network_password_sync()
It only succeeds if you check one of the checkboxes... If no checkboxes are checked, it returns nothing...

I will keep looking, there may be other methods in the gnome_keyring library that allows accessing temporary passwords, I hope so anyway :)
Comment 15 Dmitri Fedortchenko 2007-04-17 00:15:40 UTC
I am submitting a patch for the xine backend. (totem-xine-http-auth-fix-0.diff)

Unfortunately, I still have not found a way to actually access the password entered by the user unless at least one of the checkboxes is checked in the password dialog... Still, it works nicely and allows you to watch movies from HTTP servers with authentication enabled without having to manually type in the username/password into the URL every time.

I think it probably needs more work (especially the non-checkbox issue), but at least it might a good start?
Another thing that would be nice to address, is the fact that right now the xine backend searches the keyring even when accessing unprotected urls... This might be avoided if gnome-vfs can tell us whether the file is protected or not...

In the end maybe it might be a good idea to actually use xine's own gnome-vfs plugin to avoid this issue altogether?
Comment 16 Dmitri Fedortchenko 2007-04-17 00:16:47 UTC
Created attachment 86463 [details] [review]
Patch to add username/password from keyring to an URL before passing it to xine-lib
Comment 17 Dmitri Fedortchenko 2007-04-17 12:58:16 UTC
Created attachment 86496 [details] [review]
Improved patch to add username/password from keyring to an URL before passing it to xine-lib   	 

After some helpful pointers from a friend, I removed a few useless strdup calls and made a few minor changes to the original patch.
Comment 18 Dmitri Fedortchenko 2007-05-09 15:05:27 UTC
Did anyone have a chance to look into this patch? ;)
Or am I on the wrong track?
Comment 19 Bastien Nocera 2007-05-09 15:20:54 UTC
That looks alright, it would still be better if xine-lib had an authentication infrastructure.

Discussion was at:


You need to add a separate check for gnome-keyring, and it should only be enabled if --enable-gtk=yes. And you need spaces before opening brackets, as in the rest of the code.
http://thread.gmane.org/gmane.comp.video.xine.devel/8508/focus=8587
Comment 20 Dmitri Fedortchenko 2007-05-11 14:35:34 UTC
Created attachment 88014 [details] [review]
patch to add username/password from keyring to an URL before passing it to xine-lib 

I put spaces before brackets now.

I agree that xine-lib should have authentication. I checked out the thread you sent and it was informative. I'll delve into that topic to see if I can do anything to help.

However, while we wait, this little patch helps out at least for HTTP authentication.
Comment 21 Dmitri Fedortchenko 2007-05-11 14:41:54 UTC
Created attachment 88015 [details] [review]
patch to add username/password from keyring to an URL before passing it to xine-lib

I missed one "space before bracket" thing...

Not sure if it's worth a new patch, but since I am a n00b at this I'll submit it anyway. I should have checked harder the first time :/
Comment 22 Bastien Nocera 2007-05-11 14:44:15 UTC
I have one concern though. Won't this make Totem access the gnome-keyring even
if no authentication is required, potentially prompting the user for his
keyring password, even if not required?

Maybe we should add the authentication info in xine_error, when
XINE_MSG_PERMISSION_ERROR is called the first time around.

Comment 23 Dmitri Fedortchenko 2007-05-11 15:03:24 UTC
Yeah I actually mentioned this when I uploaded the first version of the patch...

I thought gnome-vfs could be used to tell us if the file is protected, but you are right in that using the XINE_MSG_PERMISSION_ERROR is probably best.

The problem is however that xine-lib does not return XINE_MSG_PERMISSION_ERROR, it returns XINE_MSG_CONNECTION_REFUSED. I submitted a patch for this to xine mailing list, but nothing came of it (probably because I did not submit it properly, as it was my first ever patch in the open source world heh).

If you look at the patch you can see where the problem originates and how the tiny patch solves it.

http://article.gmane.org/gmane.comp.video.xine.devel/16756

To get around this problem, we can look at what xine-lib currently returns:
input_http: http status not 2xx: >401 Authorization Required<

What we can do is substring the error message for "http status not 2xx: >401" and that way we can know what we are in fact required to authenticate. This could be a temporary solution until xine-lib returns the correct error message. AND we can add the check for PERMISSION_ERROR so it works when the problem is solved...

What do you think?
Is it too dirty or are we on to something?
Comment 24 Bastien Nocera 2007-05-11 15:10:43 UTC
I'll look at your patch, and commit it. You should be able to fix Totem to use XINE_MSG_PERMISSION_ERROR to check whether we need a password at all.
Comment 25 Dmitri Fedortchenko 2007-05-11 15:14:31 UTC
(In reply to comment #24)
> I'll look at your patch, and commit it. You should be able to fix Totem to use
> XINE_MSG_PERMISSION_ERROR to check whether we need a password at all.
> 

Great, I am looking into it right now.
I am probably not going to have time tonight (going to theatre with my gf), but I hope to have something before the weekend is over.
Comment 26 Bastien Nocera 2007-05-11 15:31:37 UTC
Committed:
http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=2997606ae794;style=gitweb

Now you can go on to fix this bug :)
Comment 27 Dmitri Fedortchenko 2007-05-18 15:44:04 UTC
Created attachment 88402 [details] [review]
patch to add username/password from keyring to an URL before passing it to xine-lib

This patch only checks the keychain if access was truly denied.

It first attempts to load the file without accessing the keychain, then if a permission error occurs we try to open the file again. 

At this point if the file still fails to open, a new error message is set detailing the problem.

I am not sure if I actually need to call xine_close (bvw->priv->stream); before calling xine_open again...
Comment 28 Dmitri Fedortchenko 2007-05-26 13:33:44 UTC
Have you had a chance to look at the patch? :)
Comment 29 Bastien Nocera 2007-05-30 16:48:52 UTC
Nope, and it looks like xine-lib tip added the XINE_MSG_AUTHENTICATION_NEEDED message which is even better than checking for XINE_MSG_PERMISSION_ERROR...

If you could update your patch to use that instead, I think it would be pretty much ready to merge (and you're allowed to ask for the password then).
Comment 30 Dmitri Fedortchenko 2007-07-14 09:43:02 UTC
Created attachment 91766 [details] [review]
patch to add username/password from keyring to an URL before passing it to xine-lib

I disappeared, then I came back (took a while! sorry!)

This patch uses the bacon BVW_ERROR_FILE_PERMISSION constant. If xine sends XINE_MSG_AUTHENTICATION_NEEDED or XINE_MSG_PERMISSION_ERROR then this error number is set. I added a new set of error messages ("Authentication is required to access this file." or "Authentication is required to access this file or stream.") for authentication required errors, however underneath the error code is still the same as before....

I am not sure if this is the best way to do it. Perhaps bacon needs a new constant for authentication like BVW_ERROR_AUTHENTICATION_NEEDED?

Also the XINE constant is present in xine-lib 1.2 and above, so I placed an #ifdef around it for now since the autogen requirement for xine-lib is not yet 1.2.
Comment 31 Philip Withnall 2007-07-15 09:00:48 UTC
Shouldn't add_auth_to_uri be static?
Comment 32 Bastien Nocera 2007-08-26 00:22:58 UTC
I committed the patch with a number of changes:
- Only use this functionality if using the GNOME frontend, not the GTK+-only one
- Return NULL if we didn't change the MRL to get auth information from (so that we know when the MRL didn't change)
- Don't try to reopen the stream again if we didn't get a changed MRL
- Fix a leak of GnomeVFSURI in add_auth_to_uri
- Fix indentation and coding style

2007-08-26  Bastien Nocera  <hadess@hadess.net>

        * src/backend/Makefile.am:
        * src/backend/bacon-video-widget-xine.c: (xine_event_message),
        (add_auth_to_uri), (bacon_video_widget_open_with_subtitle):
        Patch from Dmitri Fedortchenko <zeraien@gmail.com> to make
        the backend try to get authentication information from the
        GNOME keyring when it gets a permission denied on HTTP.
        (Closes: #418316)