In collaborative scenarios, there is an almost classic problem: Keeping all participants' files up to date. I saw scenarios of wandering USB-Sticks, have participated in excessive (ab-)use of e-mail as well as use of classic SCM such as SVN, Git, ... . All of these have their pros and cons. And then I recently encountered this feature coming with Microsoft Office that made my eyes glare.

Introduction

When working with people from CS, you use SCM when it comes to project working. This is fine. But once people from Humanities get involved, problems raise. You have to teach them the idea of SVN, Git or whatever. You probably have to walk through installing it on their computers, which makes you even more probably their go-to-guy in case of problems with that specific computer. Oh, and of course you need a repository. Then you start working. You want to use TeX but the Humanities people are notoriously familiar with MS Office, so yeah, ok, you will use it too. After all, in many cases it's less work to swallow your pride than to teach someone LaTeX who has never heard of it before and who will probably never use it once your project finished (making it a loss of time to both of you).
In this setting, you often end up with mail exchange of documents. If your partners are disciplined, all of you follow a common name scheme using a revision within the file name. In best case, Word's difference markup is used (which is really helpful). Worst case, you have to review the whole documet for changes manually.
Anyway, this article covers the problem of file exchange using WebDAV as a solution.
One warning ahead: The file will be locked when opened. Thus, concurring write access is very limited. The first to open the file gets full rw-privilege; concurring access is restricted to read only. On the plus side: When Alice has closed the file, Bob will be notified that he is now able to a) retrieve Alices' changes, b) review them and c) save his version to the sever. I have no Idea what happes if Chantal joins the game.
Anyhow, I came across this idea of Word and WebDAV since I had to use a Microsoft Sharepoint and noticed Word's integration with it. Since Microsoft Sharepoint is somewhat costly, there had to be a minimal version for non-corporate use. Here it is.

Settig up the Server

I will describe the necessary steps to get this working using Apache 2.2.

The first need: The Server must suppert WebDAV.
Yeah, it does work -- not encrypted, no user restriction. Everyone can read, write, delete the file. As unusable as it is, it's a good starting point. WebDAV can be activated using the following lines in httpd.conf or a file included from httpd.conf.

    
        DAV on
        AllowOverride All
        Order allow,deny
        allow from all
    
Try using this WebDAV share using cadaver, which is a nice command line interface, similar to ftp(1). Once you got that working (upload a document to the server, see it on the server, download it from the server -- all without authentication), try Word. Make up a new document, type something, save it. See below for how to save to a WebDAV from within word :)

Of course, you do not want this. You want it secured with SSL (so intercepting parties have a hard time reading your document unless Word copies it to them anyway) and you want to have some kind of authentication to restrict read and write access.
Authentication can be solved using classig basic authentication. SSL can be used, as well. Since you may not have access to a `real' certifier (or do not want to spend the money), you can also use self-signed certificates (which is not inherently insecure but needs additional effort when inviting people to use the WebDAV-Share). Since my setup targets a Subdomain, the final version looks something like this:

DavLockDB /tmp/DavLock

BrowserMatch "Microsoft-WebDAV-MiniRedir/5.1.2600" redirect-carefully
BrowserMatch "Microsoft-WebDAV-MiniRedir/5.2.3790" redirect-carefully

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL


<VirtualHost *:443>
    ServerAdmin webmaster@dummy-host.example.com
    ServerName someserver.tld
    ServerAlias alias.someserver.tld

    DocumentRoot "/path/to/httpdocs"
    ErrorLog "/path/to/logs/error_log"
    CustomLog "/path/to/logs/access_log" combined

    CustomLog "/var/log/httpd-ssl_request.log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

     SSLEngine on
     SSLCertificateFile /path/to/cert.crt
     SSLCertificateKeyFile /path/to/key.key

    <Directory /paht/to/httpdocs>
        DAV on
        Allow from all
        AuthName "Login validation"
        AuthUserFile /paht/to/auth/file
        AuthType basic
        ForceType text/plain
        <LimitExcept OPTIONS>
                Require user username
                Require valid-user
        </LimitExcept>

        Options FollowSymLinks +ExecCGI
        Options +Indexes
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>
...tough it took me an hour of googling for some of the options, not that scary. In fact, I needed most of the time to find that it is a good idea to add Listen 443 to the config in httpd.conf, if I want the server to listen for incoming connections on Port 443. But that's pretty much it.

Important supplement: How to get the certificate fingerprint. In the next section, you will need the certificate's fingerprint to transmit it to your coworkers using a different channel than transferring the certificate file (such as by SMS). To get the fingerprint, you may issue the following command:

openssl x509 -noout -in path/to/crt/file -fingerprint

Settig up the Client

Prerequisite: The Microsoft WebClient service needs to be installed and probably also running (maybe Word will start it, if necessary). On a Remote Desktop Server it probably needs to be installed using the Server-Manager's "Features" Snap-In. Click "Add feature", and install "Desktop Experience" (dt. "Desktopdarstellug"). Just don't ask, why this covers Webclient, but it does.

You first try should be using the WebDAV without any of encryption or user authentication as they pose additional opportunities for bughunting. Once the server is running and it's function has been tested with cadaver, you can use Microsoft Word.

Just open the Save As-Dialog and enter the web location. It will show the web folder contents. Close word. Open the file using the very same way. Notice the Save icon's change.
It now promises to check for other user's changes. Well, seemingly that function still has some problems.

Next try is after you sucessfully used the WebDAV with encryption and authentication with cadaver. If you are using a self signed certificate, you run into a problem. Word will bluntly discard any of your tries to access the WebDAV, stating that the filename is invalid. What has happened: It wasn't able to veritfy the certificate (of course not) and flagged it invalid. And invalid is invalid. Not a valid filename. Period. This brings us to the somewhat darker secrets of Microsoft Windows -- whose database is used to validate the Certificate? Internet Explorer, of course. This is bad news and good news. Bad news is the still persisting connection between IE and ... everythig. Good news is that we now know how to make our certificate valid.
All you have to do is take the servers .crt file (not the key file, this cannot be stressed enough!) to the windows and install it as trustworthy:


Doubleclick it...
And now we have the classic problem coming with self signed certificates: There is no way to validate the authenticity of this very file. You need to trust it by heart.
We want to install the certificate.
We want to select where to install the certificate, so click "Browse" (dt. "Durchsuchen").
We want to install the certificate as trustworthy root certificate.
Now, this dialog is crucial. If you want to make sure your encryption is safe, you should distribute this fingerprint using a different way than you distribute the certificate file. E.g. by telephone while distributing the file using mail. If this number does not match the original fingerprint something is very fishy and I suggest you do some serious forensics on your IT infrastructure.
All done.

By now, you should be able to enter a https-Path in your Microsoft Word and it will prompt for login credentials. You then can work on shared documents. Voila.

Does that work with (Open|Libre|InsertYetAnotherForksNameHere) Office?

Currently, I don't care. If you tested it, you may send me an mail and I will update this section.

Stichworte:


Impressum