simple-transfer

a simple web app for asynchronously transferring single files

For the extended README (a.k.a. detailed information), please go to http://simple-transfer.rasenplanscher.info

Introduction

This is a little something I produced in response to my company's frequent problems with email attachments sent across different infrastructures. My solution was simple: replace attachments with download links. Direct file transfers just work far more reliably than email attachments.

Installation

As everything else here, this should be simple:

• git clone or download and unpack the archive
• make sure that your web server can write to these directories:
  • files
  • logs
  • metadata

Well, that's it already, now you'll want to configure your brand new web app -- see the next section for that.

Configuration

There are several ways to customize this bugger without messing with its internals:

• configuration file -- set some parameters that change the behaviour
• users directory -- setup users in multi-user environments
• snippets directory -- change the markup output
• public directory -- change the non-markup output
• htaccess file -- limit uploadable file sizes and time limits

Note that you need not change any setting -- this should run out of the box, as long as your server meets all the requirements. But you should make a decision as to which mode of authentication to use and set that up. If you stick with simple you should change the passes for that. Otherwise see the section about the users directory and replace the samples with real users.

Configuration File

The file by the name of CONFIGURATION contains the configuration for the application's behaviour. The settings have this format:

"key": "value"

Don't change anything other than the values!

The configuration file is annotated, so look there for details.

Users Directory

If the authentication mode is set to multiuser or digest the users directory comes into play. It contains plain-text files. These represent valid users. The directory at first contains two sample users that illustrate the whole thing. One is called user, the other one digest.

The file name is used as the user name. Each file contains two key/value pairs. For multiuser authentication, one key is pass, the other one is list. For digest authentication the two keys are hash and list. To see how the files are formatted, look at the sample files -- too simple to explain.

The list key can have a value of 0 or 1. If it is 1, the user may access the list view; if it is 0, he cannot.

The pass key takes the user's pass code. The sample user user has the pass password.

The hash key takes the user's pass digest hash. This hash is generated by applying the MD5 algorithm to the string that results from concatenating the the user name, the realm and the pass code, with colons in between:

username:realm:passcode

To get that hash, you can do this in most shell environments:

echo -n 'username:realm:pass' | openssl md5

The sample user digest has the pass hash, so its hash is calculated like this (as long as the realm setting wasn't changed):

echo -n 'digest:simple-transfer:hash' | openssl md5

Snippets Directory

The directory snippets contains the HTML part of the application.

Note that the final pages are expected to be valid XHTML. Also, for MSIE it is delivered as text/html, so mind compatibility.

Public Directory

This contains all static files, i.e. images and style sheets. Changing this is completely straightforward.

Htaccess File

As this application is developed for the Apache web server it makes use of the .htaccess file.

Known Issues

• Basically no error handling
• Low level of security unless digest authentication is used
• Digest authentication does not support these optional features:
  • auth-int
  • stale
  • MD5-sess
• file fields look wrong in every browser -- this is due to all the browser developers treating them as special in regard to stylability