GNOME Bugzilla – Bug 549415
gvfs refuses to authenticate to webdav share after mounting
Last modified: 2018-09-21 16:25:03 UTC
Please describe the problem: Using Ubuntu Hardy, we cannot delete or create files or folders on our webdav share anymore. Connecting to a Gallery2 webdav share (nautilus dav://hostname/g2/w/) which allows anonymous reading works. When trying to upload a photo, we expect an authorization dialog, but nautilus only says "Authorization required", letting me skip or cancel. This works as expected in Feisty and in some other operating system. When we disable anonymous access to Gallery2, we can authenticate through Nautilus at mount time and uploading works fine. We have gvfs version 0.2.5-0ubuntu2 installed. Steps to reproduce: 1. nautilus dav://hostname/g2/w/ 2. copy file to nautilus window Actual results: nautilus gives an error saying "Authorization required", letting me skip or cancel Expected results: we expect an authorization dialog Does this happen every time? Yes Other information: Tcpflow of a failed session shows the obvious: first a PROPFIND on the directory, server replies 207, then a HEAD on the file gets a 401, then the file gets put and the server replies again with a 401. When I try to read the gvfs source code, I see in daemon/gvfsbackenddav.c that at mount time authentication is governed by a function called "soup_authenticate_interactive". After a successful mount, the authentication handler gets switched to soup_authenticate_from_data. That sounds a little suspicious to me. I am hardly a programmer, so I have not yet gotten it to work when I play with the handlers, but maybe someone else can.
Switching the authentication handlers is totally on purpose. When we are doing the mount we are trying to discover where the root of the dav share is. During that we also handle authentication. It is also only possible to ask the user for username/password during the mount operation, so if we don't get a 401 there we have no choice to ask the user for it again later. And I think that is the very problem here: The PROPFINDS succeeds during mount so we don't ask for u/p so we don't have them cached later. Maybe we should do a HEAD on the the requested mount target as well to make sure we hit 401. This is of course hacky since you might have asked for a directory instead of a file. Not sure what's the correct way to do here. Maybe fix the server to also require u/p for PROPFIND?
I'm seeing a similar issue, for me it seems as if gvfs just completely fails to use authentification. I used nautilus (on Debian unstable, which somewhat is a version mess right now, sorry...) to connect to the webdav share. I enter a user name, and I'm asked for a password next. Then I get the same "Authorization required" message, and the web server log only shows a single request: [02/Jun/2009:14:52:02 +0200] "OPTIONS /webdav HTTP/1.1" 401 490 "-" "gvfs/1.2.2" So I have the impression that the username and password I entered were actually never used. (Confirmed using Wireshark - gvfs didn't even try to authenticate using the given user name and password!)
Created attachment 136943 [details] Wireshark trace
Same problem with "gvfs/1.2.2" as shipped with Ubuntu 9.04. Attached a Wireshark trace. As Erich mentioned, there is no attempt to use the password.
Using gvfs directly from the command line seams to be working fine: xavier@desktop:~$ gvfs-mount dav://webfolders.vsilicon.net/xavier.php/ Enter password for Vista Silicon Intranet User: xavier Password: xavier@desktop:~$ gvfs-ls dav://webfolders.vsilicon.net/xavier.php/ vista.jpg config.tar Thumbs.db toto.jpg vista (2).jpg xavier@desktop:~$ gvfs-copy dav://webfolders.vsilicon.net/xavier.php/vista.jpg . xavier@desktop:~$ file vista.jpg vista.jpg: JPEG image data, JFIF standard 1.01 The server log shows that authentication went smoothly. 192.168.168.7 - xavier [18/Jun/2009:22:11:10 +0200] "PROPFIND /xavier.php HTTP/1.1" 207 4344 "-" "gvfs/1.2.2" Moreover once the webdav share is mounted it appears in nautilus. Trying to leads to the error: Could not open location 'dav://webfolders.vsilicon.net/' Not a WebDAV enabled share So maybe the problem is in nautilus instead of gvfs. There is a ticket for it in launchpad (https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/260988)
(In reply to comment #5) > Using gvfs directly from the command line seams to be working fine: It does not for me with the Gallery 2.3 [1] installation. So Xavier’s problem might be a different issue. $ gvfs-mount davs://hostname/gallery2/w/ $ gvfs-ls davs://hostname/gallery2/w/ $ # nothing happened Using cadaver [2] also logs in without authentication/authorization in the beginning, but issuing `ls` is following by asking for credentials and works. Are the following solutions feasible? 1. In the »Connect to server«-dialog, if the user enters a username authorization/authentication is always forced. Or maybe add a checkbox for this and an option to `gvfs-mount`? 2. If HTTP Error 401 is returned open up a authorization dialogue. $ dpkg -l gvfs […] ii gvfs 1.2.3-3 userspace virtual filesystem - server Please tell me, what other information you need. [1] http://gallery.menalto.com/ [2] http://www.webdav.org/cadaver/
The problem as far as I experienced it is gone in Ubuntu 9.10.
I believe this bug has just effected me when using Nautilus 2.28.1 (Ubuntu 9.10). I am running a WebDAV server, configured as follows: <Directory "home/directory/to/webdav/folder"> DAV On DAVSATMaxAreaSize 256000 Options Indexes MultiViews AllowOverride None Order allow,deny allow from all AuthType Digest AuthDigestDomain https://dav.example.com/webdav AuthName "WebDAV" AuthUserFile /home/directory/to/webdav/.digest_pw <Limit PUT POST DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require valid-user </Limit> </Directory> The above configuration results in anonymous WebDAV browsing succeeding but any attempt to edit or add files failing with an error. "Error creating directory untitled folder. There was an error creating the directory in davs://user_admin@dav.example.com/webdav/folder2. Authorization Required" Forgive rather limited comparison but the above configuration does work as expected in Winodws XP; anonymous browsing is successful followed by a login/password prompt when a 'Limited' request is made. The problem can be worked around by editing the server config to include 'PROPFIND': <Directory "home/directory/to/webdav/folder"> DAV On DAVSATMaxAreaSize 256000 Options Indexes MultiViews AllowOverride None Order allow,deny allow from all AuthType Digest AuthDigestDomain https://dav.example.com/webdav AuthName "WebDAV" AuthUserFile /home/directory/to/webdav/.digest_pw <Limit PROPFIND PUT POST DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require valid-user </Limit> </Directory> This then results is any WebDAV access at all requiring a username and password.
*** Bug 604070 has been marked as a duplicate of this bug. ***
The problem here was that the path the backend supplied back to the client was relative to the mount_prefix of the mount; so the client needs to resolve that path and append the mount_prefix before creating a new GDaemonFile with the new path. Fixed on master with the following commit: commit d4049d3ac0741c3700a029a24c869dfafd840dc2 Author: Christian Kellner <gicmo@gnome.org> Date: Thu May 12 10:53:04 2011 +0200 daemonfile: Re-root the path in set_display_name () The path we get as a result of a set_display_name operation has to be re-rooted with the mount_prefix of the specific mount. This fixes the "Location not mounted" error that we currently get for e.g. WebDAV mounts with a mount_prefix after renaming of files. And the supportive commits: commit 7a2942f7bdf39ebfc31ea90c0685b5890d30964d commit 66bc0189d836130768df41900f3cf29723bbd870
Ups. wrong bug. Sorry. Reopening.
Just to say that this bug is alive and kicking on Fedora 19 (gvfs-1.16.1-1.x86_64) matej@wycliff: ~$ gvfs-mount davs://matej@luther.ceplovi.cz/dav/ matej@wycliff: ~$ gvfs-ls davs://matej@luther.ceplovi.cz/dav/ pepik-kase.ogv gnote Palm Sunday.pdf duplikaty-1.pdf cert9.db DPFDP4-7104130330-20130330-232326.pdf matej@wycliff: ~$ gvfs-copy projekty/import-ldif/carddav.ldif davs://matej@luther.ceplovi.cz/dav/ Error copying file projekty/import-ldif/carddav.ldif: HTTP Client Error: Authorization Required matej@wycliff: ~$
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/56.