To date all web publishing to www.udel.edu has been done using the FTP protocol and its encrypted counterpart, SFTP. The end-user wishing to upload resources to a web site opens an FTP/SFTP connection (in his/her software of choice) to copland with a target directory under /www/htdocs. Files and directories are than copied to/from copland per the particular software: often the ubiquitous drag-and-drop interface is supported, for example.
Behind the scenes the software is interacting with the Unix command line on copland on the end-user's behalf. This implies that the FTP/SFTP methods for uploading web content are affected by the intricacies of Unix file ownership and privileges: the end-user must have write privileges on a directory/file in order to modify it. That privilege derives from either the end-user's being the direct owner of the directory/file or a member of the Unix project which owns the directory. Ownership is not enough: the user and Unix project owners of a directory/file must also be explicitly granted the write privilege for the directory/file.
If the preceding paragraph seemed convoluted or downright confusing, you are not alone. Unix file permissions can be difficult to grasp, and even when they are initially setup properly on a web directory, circumstances arise which alter ownership or privileges in such a way as to make a file or directory immutable to users who were previously able to change it. In such instances, end-users have no choice but to call the IT Helpdesk and request that central IT "fixup" the directory and files.
Though file ownership and privileges tend to be the most prominent source of frustration with web publishing to www.udel.edu, there are other concerns. End-users continue to use the unsecured FTP protocol to interact with copland, which means each time resources are uploaded or downloaded the user's UDelNetId and password are being sent in human-readable form across the Internet. Use of such protocols runs contrary to everyone's desire to protect one's username and password from theft.
Naturally, since the data being sent via SFTP is secured (hence the "S" in "SFTP") via encryption, the UDelNetId and password are not sent in a form which can be intercepted and stolen. However, the aforementioned problems with file ownership and privileges remain.
A Unix project allows multiple users to act as a single entity. It is common practice at UD that for any web site created which will be served by www.udel.edu, a Unix project is created in order to group together the (often multiple) end-users who will be maintaining the site. End-users who do an extensive amount of web development can wind up being a member of many projects. This is not itself a problem: however, copland recognizes an end-user's membership in a maximum of 16 projects. The moment an end-user is added to a 17th (and 18th, 19th, et al.) project, that project is not seen by copland and the end-user cannot work with the web site's directories/files!
Historically, end-users in such a predicament have been asked to reevaluate their project membership and request removal from any which are deemed unnecessary. At some point 16 projects may truly be not enough for an end-user, but copland will continue with its membership limits.
Another factor which complicates web publishing for the end user is the use of server-side includes in pages (the canonical SSI reference materials can be read here). At its most basic, server-side includes allow the user to do the following dynamic things to the HTML being sent to a web browser:
The web server will only look for SSI directives and do the wonderful dynamic things mentioned above under two conditions: your file uses the .shtml extension (rather than .html), or the file has the executable bit set in its Unix permissions. UD's web publishing guidelines have always promoted the second option, which has led to many end-users simply setting the executable bit on everything in a web directory, whether it contains SSI or not. Delivery of an HTML file by the web server is much slower if it must search for SSI directives, so setting that bit unnecessarily slows the delivery of that page as well as the overall performance of the web server.
WebDAV — short for Web-based Distributed Authoring and Versioning — is one solution to the issues with FTP/SFTP management of web directories. For an extensive review of WebDAV, the Wikipedia article is quite useful. In short, though, WebDAV makes use of the same technologies that already power web servers to add the capability for not just reading the contents of a URL, but also writing information to the URL.
Under WebDAV, the end-user's web directory would be owned by the web server rather than by a specific UDelNetId and Unix project. Ownership and privilege issues would never arise because the end-user has no way of changing any owner or privilege properties on the files and directories.
But if the web server owns the web directory, how does an end-user upload files? Consider what transpires when using FTP/SFTP: the user authenticates using a UDelNetId and password in order to establish his/her identity. The FTP/SFTP server on copland then performs commands as though it were that user. Authorization to write to a particular directory or file comes from the Unix ownership and privilege properties for that directory or file. WebDAV also requires the end-user to provide a UDelNetId and password to authenticate. However, the web server authorizes the end-user's actions independently: it is provided with a list of UDelNetIds and Unix projects which should be granted access. If the end-user appears in that list (either directly or by virtue of being a member of a project on the list) the user is allowed to write to the directory.
This form of access control is comparable to proxy voting. At a large corporate financial meeting not every stockholder can be present; however, a vote to increase the number of shares will be taken at the meeting. A group of stockholders may decide to elect a single person who will attend the meeting to act in their stead and cast their vote for them. The authentication and authorization stages outlined above are equivalent to the stockholder's receiving a ballot and handing it completed to the proxy. The proxy then determines where and how to actually commit the ballot to the voting box. Under WebDAV, the web server handles all of the directory/file operations on the server as the end-user's proxy, so long as the end-user can authenticate and is authorized.
Web servers impose no limit on the number of UDelNetIds or Unix projects that can be added to the access control list for a URL. Whereas FTP/SFTP to copland allowed a single UDelNetId and a single Unix project to be granted access to web resources, WebDAV can be configured to allow any number of users and projects. For example, suppose OCM is creating a web site for the UD Low-Temperature Water Dance team2. The Team has setup a Unix project, 0423, and OCM already uses project 0798 for web development. Historically, OCM would had to have themselves added to project 0423 for the duration of the web site development and maintenance (which contributes to the issue of 16+ project memberships, of course). Under WebDAV, both projects can be concurrently granted access3. So one secondary benefit is less project membership maintenance!
Recall the server-side include and executable bit discussion from the previous section? As an added benefit of transferring files to and from a web directory using WebDAV, the system handles setting or unsetting the executable bit based on whether or not the file contains SSI directives. This feature thus removes all need for the end-user to understand Unix file permissions. It also keeps the server happy because SSI is only used where necessary.
1 This is how the OCM web modules are primarily implemented, for example.
2 Or "ice skaters" as you may also know them.
3 Ironically enough, moving to WebDAV will actually eliminate many instances of users with more than 16 project memberships!