bcms_webdav

== WebDAV

Allow access to a BrowserCMS site via WebDAV. The primary intent of this module currently is to allow bulk upload of files using an FTP client. Clients which support WebDAV in addition to FTP may be used to review and upload/download Files. This module is implemented as as Rack Middleware.

For more information on WebDAV see: http://en.wikipedia.org/wiki/WebDAV

=== Features

• Authorized users can list pages, sections and files that exist in the content library.
• Authorized users can download files via WebDAV.
• Authorized users can upload files via WebDAV.
• Users must have 'Administer CMS' permissions in order to access resources via WebDAV.
• Users can use their normal cms username and password.

Note: Currently this module is tested to work on Passenger and Mongrel. Other rack servers may work, but implementations for file upload differ slightly.

=== Clients

In order to take advantage of this module, users will need a WebDAV client. Many FTP clients will support this, including:

• Transmit (Mac OS) - http://panic.com/transmit/
• CrossFTP Pro (Windows, etc) - http://www.crossftp.com/

This module has been tested with both of the above clients. In addition, operating systems support accessing WebDAV servers via mounted drives. See: http://en.wikipedia.org/wiki/WebDAV for more discussion.

=== Installation

$ gem install bcms_webdav
$ rails g cms:install bcms_webdav

In your config/environments/development.rb, add the following:

config.middleware.use Bcms::WebDavMiddleware, :port=>3001

This configures the WebDAV server to listen on port 3001 for WeDAV requests in development. To access the WebDAV API, you will need to start another rails server instance like so:

script/server --port=3001

==== For production

In your production.rb, add the following:

	config.middleware.use Bcms::WebDavMiddleware
	

In production, a subdomain should be used rather than a port. You will need to configure another subdomain on your webserver, much like the cms. subdomain is used for the admin interface. The default subdomain is 'webdav'. Here's an example apache config file, with a new subdomain configured:

 <VirtualHost *:80>
  ServerName webdav.mysite.com
  DocumentRoot "/var/sites/mysite/public"
  RailsEnv production
  <directory "/var/sites/mysite/public">
    Order allow,deny
    Allow from all
  </directory>
</VirtualHost>

This means there should be a total of three domains in place for a site in production:

• www - Main site accessed by the public
• cms - Site access for administrators
• webdav - Site access via WebDAV

==== Alternate Subdomains

You can change the subdomain that this module listens for requests on via:

config.middleware.use Bcms::WebDavMiddleware, :port=>3001, :subdomain=>"dav"

This would change the subdomain from 'webdav' to 'dav'. This webserver config file would also need to be changed as well.

==== Subdomains in Development

Rather than run two server instances locally, you can take advantage of subdomains. Start by modifying your 'hosts' file to make 'webdav.localhost' map to your local development environment, like so:

127.0.0.1 webdav.localhost

Then configure the module so its no longer listening on port 3001, like so:

config.middleware.use Bcms::WebDavMiddleware

Now you can make web requests to localhost:3000 and WebDAV requests to webdav.localhost:3000

== Notes

This is an incomplete implementation of WebDAV, so many operations are not explicitly supported, such as:

• Moving - Users cannot move files or pages.
• Get/Put Pages/sections - Users can't download or upload pages or sections.
• Edit/Create Pages/section - Users can't edit/rename or create new sections.

== Known Issues

• All files are uploaded as 'FileBlocks', regardless of whether they are images or not.
• All content_types are set to 'application/octet-stream' regardless of their actual type.
• Links do not appear in the list of content items returned.
• Uploading a file with a space in it will not replace the existing file. Since we convert spaces into _, they are treated as two separate resources.
• Refactoring to avoid the need for configuring the middleware is possible. Engines can self setup middleware now.

=== Performance

This module almost certainly needs performance testing when dealing with larger sites. Certain FTP clients will make more requests for resources than others. (CrossFTP seems 'chattier' than Transmit for instance).