General developer forum

At loooooooooong last, a credible proposal for WebDav implementation in Moodle! I've been waiting for this for years, ever since we switched from good old WebCT to great new Moodle. If it's going to be in moodle 2.0, however, this means waiting for at least another year or two, I guess.
Joseph

Note: Unfortunately, WebDAV does not work well with very large files -- if you are planning on routinely hosting files over 100MB, WebDAV will fall short of your expectations. For the occassional large file, it will do just fine. (AFAIK anyway - I have to test how it works with large files and document it)

It doesn't? How come?

I am definitely interested in testing this, especially as I was hoping to implement something similar whenever someone would free me up some time. (But I was thinking of something a bit further away from moodle with with mod_dav and PAM or similar)

Martín, this will be great when it's in Moodle core


It is possible to get a certain amount of information - if I remember correctly IE6 will pass the cookie credentials if WebDAV is accessed via a link like this:

<a href="http://moodleurl/fallback.htm" folder="https://moodleurl/webdav/164/" target="_blank" style="behavior:url(#default#AnchorClick)">File Manager (WebDAV)</a>

Yeah, it's ugly and will only work under certain (Windows/IE) conditions, but it's worked OK for us here. I just use Nautilus or cadaver for accessing it anyway.

With the version I have just pushed out,

• All the "read" operations are supported.
• Access controls work as expected: you need moodle/site:webdav to connect, and then moodle/course:managefiles to be able to see & manage files within a course.
• It protects and hides all the important "non-user-serviceable" directories.
• It relabels all the course directories to the course shorname, using the displayname feature of WebDAV. Unfortunately, not every WebDAV client supports it -- the good ones do though!

Is anyone else playing with it?

Is WebDAV actually any use? Most of my experience with it has been fairly negative - horribly unreliable. I'm quite prepared to accept that it might just be me or failure to find a reliable client.

Is there any route to use a rock solid technology like ssl? Anyway it's certainly interesting stuff as file sizes aren't getting any smaller.

Pushed out more updates

• We use moodle's own mimeinfo() function
• Now there's a capability defined, and Course Creators get it by default (admins have it via "doanything" anyway).
• The $CFG configurable options are settable via Admin->Server
• Session TTL is configurable too

And I've done a bit of testing with different clients. One bit of excellent news is that clients can (and do) chuck large file transfers, so my earlier misgivings about managing large files via WebDAV. I have managed to transfer several 700MB files from Windows and Linux (using davfs2) with my Apache/PHP processes stable at 24MB memory usage. I am impressed with the clients.

Windows Server 2003

works great, and it (suprisingly) works well with non-ASCII characters. I can create, access and move around a file called Martín ;) It supports Displayname so it will show the course shortname. The only issue is that it sometimes gets confused around new directories and deleted files. Pressing F5 (refresh) fixed it for me every time.

This page has been extremely useful http://www.greenbytes.de/tech/webdav/webfolder-client-list.html - and if anyone is having compat issues it should be the first stop. My MSDAIPP.DLL is 11.0.5510.0

Linux w DAVFS2

On linux the best support is from davfs2, which works great. It supports displaynames (but it's disabled by default - edit your /etc/davfs config files). A few things don't quite work:

• It cannot see files with high utf-8 (non-ascii) chars
• Some commandline tricks don't work and crash the webdav client daemon - trying "echo 1 > foo" triggers this problem

Linux w Gnome VFS (Nautilus)

Works, does not support displaynames. The quality is patchy - I managed to crash my Nautilus session a few times, and Matt crashed it testing with large files.

CaDAVer

This is a commandline client that works on Windows, Linux, OSX and other OSs. It worked almost perfectly, but

• it does not support displaynames
• it can't see files with high utf-8 (non-ascii) chars

Litmus test

The litmus test report (attached) is fairly good. It's not perfect as we break the spec in a few places for two good reasons:

• We cleanup filenames (rules are the same as when using the file upload form). Litmus tries several tests with filenames that have funny characters - some fail.
• We refuse to store arbitrary properties. WebDAV allows clients to store any arbitrary metadata along with the file -- this has no meaning for Moodle, so we don't support it. We do have (and provide) standard properties (MIME type, size, etc) but do not allow the client to set any of those.

You can't run the litmus test against the root of moodledata, as it has all sorts of restrictions. Instead, give it the path to a course directory.

Turns out that OSX doesn't like to play with you in read/write mode unless you implement locks properly.

So I've rolled up my sleeves and implemented locks support. This requires a new DB table, so I've split the work in 2 branches:

• on mdl19-webdav the table is created from local/db so it doesn't get in the way of future upgrades
• on mdl19-webdav-forhead the table is created from lib/db -- these are the patches I'll merge into CVS HEAD once we are done

The litmus report is attached - it says:

summary for `locks': of 26 tests run: 26 passed, 0 failed. 100.0%

Edit:

I think this is mostly ready for merging into HEAD if we want it. And even 19_STABLE too after the release -- we could plan to merge it into 1.9.1 for example without the webdav locks table. Without that table OSX users get a readonly webdav mount -- that's the only visible limitation.

Hey Martín,

I was playing more with the WebDAV stuff today and i think it'd be useful if you introduced $CFG->webdavroot (or something) for the path for the webdav server to be specified. (e.g. http://my.server/webdav/moodledata-server.php ). Let me explain a bit:

The problem:
We have hundreds of vhosts (which are disparate organisations) and care very much about users transmitting their authentication details across the web (and thus enforce https for auth points). Due to the number of vhosts its not feasible for us to set a certificate [ip address] for each vhost as the present time.

To get round this issue we setup single sign-in points which have good https certificates, users don't get warnings and everyone is happy.

Unfortunately it (looks to me) like we can't separate out our authentication to take place at this login location for our webdav potential action.

My solution:
Have a single 'webdav' entry point (with the vhost specified as a param). Users details are transmitted securely to this location and we're all happy.

Unfortunately, this requires some sick and twisted jiggery pokery with SERVER varaibles, but I hacked up a quick ugly proof of concept (patch attached).

Users would browse to their secure webdav location as:
https://secure.webdav/webdav/moodledata-server.php/moodle.org/
https://secure.webdav/webdav/moodledata-server.php/demo.moodle.org/
(This assumes all vhosts are served from the same place)

And browse from there. But this requires the moodledata server to be able to be specified separately from the wwwroot

Just pushed out a couple of updates that make life more pleasant for those on Windows machines:

• Implemented the nicer weblink with the "folder" and "style" thingies. Works very well on the Windows 2003 Server machine I have access too - (but this one also handles "displayname" very nicely anyway).

• Windows clients that are part of a domain sometimes try to send DOMAINNAME\username instead of just the username. If that happens, we ignore the DOMAINNAME\ part.

... and I think we are done. Anyone testing this?

Super - as of now and thanks to MartinD all the bits needed are in 1.9 so that it will be easy to add the webdav directory, add some settings in config.php and use it.

If the code works well, we might add all the nice admin ui bits for 1.9.1 or 1.9.2. Yummy.

And there's a funny thing too -- this is the oldest bug I ever worked on: MDL-90 --

I've just set up the webdav-applyto19.patch from the Tracker on Moodle 1.9.1 and it seems to be working great. Using Webfolders on XP and Nautilus on Ubuntu works fine, except for cases where the displayname isn't supported by the client.

I've enabled webdav access for editing teachers, this works fine too, teacher accounts are able to access, upload and generally manage the files in their course. However, there's one big problem : teachers have read-only access to all other courses in the system. In our case this is kills webdav access right there : virtually no one will accept having their course's files exposed to other teachers, even in read-only.

So basically I'd like to know if there's any way I can have the webdav feature expose only those folders/courses in which the user connected is a participant/has write access.

This maybe unrelated, as this is first time I have found webdav working with Moodle.

At present we do not have webdav installed on our moodle,
but that may not be the issue.

We have Sharepoint, and have just started using webdav (network places), but we have run into this error, when using it with Moodle.

When we upload a document into moodle from our sharepoint server through our network places, it appear to upload the document but it messing up the file name and file type making the file unusable.

Example:
I select "Adding a new Resource"
I select "Choose or Upload File" then upload file
I browse to network places then a file at this location

https://portal.chaucer.sheffield.sch.uk/sites/geography/Picture Library/Coasts/swash.jpg

It appears in the form field as
C:\Documents and Settings\staff1\Local Settings\Temporary Internet Files\Content.IE5\D84SRM6X\Swash[1]

It uploads it, but names it

" Swash_1_"

And the file must be renamed with the correct file extension to to swash.jpg

Any suggestions?

Is it because Webdav is not installed on Moodle?

Thank for any help.

Steve Audus
Chuacer BEC

www.chaucer.sheffield.sch.uk

Dear all,

I have been following this thread for more than a year now, and was expecting, that WebDav would be integrated in Moodle 1.9x

Now I see, that you have still to gather all the necessary server components on your own. That's ok for me, but could someone put it all together in a mini how-to or simple check-list like this, only to see all needed components and configuration steps/options at a glance:

• apache httpd.conf or /etc/apache2/sysconfig.d/loadmodule.conf
  
  • LoadModule dav_module /usr/lib/apache2/mod_dav.so
LoadModule dav_fs_module /usr/lib/apache2/mod_dav_fs.so
  • What about authentication modules like:
    • LoadModule auth_digest_module /usr/lib/apache2/mod_auth_digest.so
    • LoadModule auth_basic_module /usr/lib/apache2/mod_auth_basic.so
  • or do we authenticate directly with Moodle's built ins?
• Moodle Tracker Patches, which ones? and in which order? there are several here:
  • http://tracker.moodle.org/browse/MDL-90
• This one helps to understand the client issues: http://docs.moodle.org/en/WebDAV_Connect
• This one should help to setup correctly but actually does not: http://docs.moodle.org/en/WebDAV_Setup
  • As others already mentioned, this one is not present in 1.9.4: In Admin->Server->WebDAV Set webdavenable to Yes
  • This role mentioned there is not in 1.9.4: The 'moodle/site:webdav' capability controls who can connect
• what else?
  • Does the Moodle-WebDav Patch Code change any directory names from course ID numbers to course short names or does it look up the short name and pass it to the WebDav client for displaying only?
  • Should we install only on our Moodle-Test-Servers or is everything ready for a running production system?
    

I really appreciate all the work done and would like to test WebDav. Rosario