[Cyberduck-trac] [Cyberduck] #7739: PUT to directory with guest read permission results in zero length file (was: Webdav PUT to directory with guest read permission results in zero length file)

Cyberduck trac at trac.cyberduck.io
Thu Jan 16 20:22:40 UTC 2014


#7739: PUT to directory with guest read permission results in zero length file
----------------------------+------------------------
 Reporter:  matthew bellew  |         Owner:  dkocher
     Type:  defect          |        Status:  closed
 Priority:  normal          |     Milestone:  4.4.4
Component:  webdav          |       Version:  4.4.3
 Severity:  normal          |    Resolution:  fixed
 Keywords:                  |  Architecture:
 Platform:                  |
----------------------------+------------------------
Description changed by dkocher:

Old description:

> Here's the scenario.  guest has read access to a directory, but not write
> permission.  The user (matthew) has write permission.  Here is what I see
> on upload say a 100 byte file.
>
> HEAD /myfile.txt (guest)
> 200 OK
>
> PUT /myfile.txt (guest, filesize=100)
> 401 Unauthorized
>
> PUT /myfile.txt (matthew, filesize=0)
> 200 OK
>
> The HEAD is coming from DAVSession.login(). This succeeds and PUT tries
> to use the same credentials.  When this fails, another PUT happens, but
> with 0 bytes (maybe the file pointer wasn't restored?).
>
> My fix was to make my server return 401 on the HEAD command, but this
> requires user-agent snooping as HEAD can't return 401 to the browser.  To
> fix authentication related weirdness in other client agent's I've made my
> server always require login for OPTIONS and PROPFIND.  That has the
> advantage of only affecting WebDav clients, not normal HTTP usage.
>
> I think there are two issues
>
> a) the second PUT sends a zero-length file
> b) recommend maybe calling OPTIONS or PROPFIND in DavSession.login()
> since those are webdav specific methods rather than HEAD which the
> browser also calls.

New description:

 Here's the scenario.  guest has read access to a directory, but not write
 permission.  The user (matthew) has write permission.  Here is what I see
 on upload say a 100 byte file.


 {{{
 HEAD /myfile.txt (guest)
 200 OK

 PUT /myfile.txt (guest, filesize=100)
 401 Unauthorized

 PUT /myfile.txt (matthew, filesize=0)
 200 OK
 }}}


 The HEAD is coming from DAVSession.login(). This succeeds and PUT tries to
 use the same credentials.  When this fails, another PUT happens, but with
 0 bytes (maybe the file pointer wasn't restored?).

 My fix was to make my server return 401 on the HEAD command, but this
 requires user-agent snooping as HEAD can't return 401 to the browser.  To
 fix authentication related weirdness in other client agent's I've made my
 server always require login for OPTIONS and PROPFIND.  That has the
 advantage of only affecting WebDav clients, not normal HTTP usage.

 I think there are two issues

  a) the second PUT sends a zero-length file
  b) recommend maybe calling OPTIONS or PROPFIND in DavSession.login()
 since those are webdav specific methods rather than HEAD which the browser
 also calls.

--

-- 
Ticket URL: <https://trac.cyberduck.io/ticket/7739#comment:2>
Cyberduck <http://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows


More information about the Cyberduck-trac mailing list