Fellow Monks,
Recent events at work have shown a need to replace/re-invent our delivery system for Work In Progress (hereafter WIP), which is presently being achieved with FTP.

This meditation will be a long one, and I assure the reader that perl is involved - in synopsis "A perl CGI content manager coupled with FTP virtual users , providing both FTP and HTTP interfaces to the same userdata, optionally HTTP is enriched with meta-data like comments, descriptions, thumbnails."


We are a video/film postproduction facility , providing services like color-grading , 3d animation, editing , visual effects ,etc. So our product is moving pictures. Much of our work is from overseas, and often most of the initial direction and feedback is done remotely. ie We courier a tape , or post an mpeg to our FTP site, client reviews the material and responds with comments and direction.

This presents a number of issues that interrupt or dis-enchant our clients from using the service. The idea is that remote clients can be delivered WIP more frequently by downloading it across the net. Sadly it would seem they're quite unwilling to use FTP client software and 99.9% of the time use a web browser, so I find myself giving up providing username, password and hostname ; instead opting for and emailing the (awful) link to the remote client. I will not begin to explain all the ways the IE is not an FTP client, nor how many companies now deny access to those fabulous port 20,21 outgoing connects. Suffice it to say that despite being the most efficient transport for the task, FTP is unsuitable for the point and clickers at the recieving end. (I'm biting my tounge whilst writing this - can you tell?).

What now

After much rumination and procrastination, I believe there is a solution that will

  • Provide a client-friendly interface to WIP data
  • Support FTP upload/download just like we always have, for the net-literate
  • Foster even better (easier) communication
  • Be more attractive to clients and prospective clients
  • Keep me from growing bored unjamming printers 9-5

I'm joking of course on that last one - I love printers - really.


I'm glad you asked! I am aware of several content engines but suspect that when production hand down their specification (they're brewing it right now), it will be so specific that a home-grown , roll your own solution may be the best way to go.

My plan is to use an ftpd that supports virtual users and can authenticate to a database , this takes care of 'keeping it like it is' for the true ftp clients and other facilities who prefer it. For the web interface, I would like to use perl CGI to authenticate to the same database, also storing user session objects and content metadata in the DB.

Thus far I have prototyped the session mechanism using PureFTPD (with --use-ldap) , openldap (with some custom schema) , and everyone's hero perl and a multitude of modules like Net::LDAP , Digest::MD5, HTML::Template and naturally, (you didn't think I'd roll that my self did you!).

I would love to see some debate on the validity of this solution, comments from monks who have travelled this road, FUD aswell since I have no doubt there are some traps awaiting me and foreknowledge is a wonderful thing

Many thanks to you for getting through the readmore I eagerly await the monastic gestalt.

Cheers! - toaster.

I can't believe it's not psellchecked
  • Comment on HTML Frontend to FTP using CGI,LDAP and virtual users

Replies are listed 'Best First'.
Re: HTML Frontend to FTP using CGI,LDAP and virtual users
by cees (Curate) on Apr 14, 2003 at 14:41 UTC

    WebDAV is the way to go here. If your customers are using windows, they can map a drive to your webdav enabled web server and drag and drop files in their file manager.

    We have used this successfully with some clients who also didn't like FTP, but were relatively comfortable using the windows file manager...

    You could stil use ldap authentication using mod_auth_ldap for Apache (if you are using Apache that is)

      I flirted with WebDAV for a while, I will look even further now - have you tried it with say OSX smb:// mounts or is that total pie in the sky? If it were possible to rely on the fact the all our clients use windows, then WebDAV is an real option. I suspect that the OS9.x , OSX , Windows 9x/xxxxx hetrogeny might find more common ground in HTTP1.1 at present.

      ++cees -thanks

      I can't believe it's not psellchecked

        I have never used OS9 or OSX, but according to the WebDAV projects page OSX definately has support for WebDAV. Also Win9x and up also support it (earlier version may need to install the 'Web Folders' update on Windows Update).

        WebDAV is an open standard, and hence you should get excellent cross platform interoperability. At it's most simple level, you could call it FTP over the HTTP protocol (which is pretty much what you were after). But it allows much more than that, especially with the power of Apache driving it.