use the application to authenticate and send the file through the application

Both ways have limitations:

Webserver:

+ fast download

+ no additional system load

-- inflexible authentication handling

Application:

+ integrated into the overall layout

+ very flexible permission management

-- the download occupies an application thread/process

A simple way to combine the two ways could be:

1. app authenticates user and checks permissions to download the file.2. app redirects user to the file accessable by the webserver for further downloading.3. the webserver transfers the file to the user.

As the webserver doesn't know anything about the permissionsused in the app, the resulting URL would be available to everyuser who knows the URL.

mod_secdownload removes this problem by introducing a way toauthenticate a URL for a specified time. The application hasto generate a token and a timestamp which are checked by thewebserver before it allows the file to be downloaded by thewebserver.

The generated URL has to have the format:

<uri-prefix>/<token>/<timestamp-in-hex>/<rel-path>
which looks like "yourserver.com/bf32df9cdb54894b22e09d0ed87326fc/435cc8cc/secure.tar.gz"
<token> is an MD5 of
1. a secret string (user supplied)
2. <rel-path> (starts with /)
3. <timestamp-in-hex>

As you can see, the token is not bound to the user at all. Theonly limiting factor is the timestamp which is used toinvalidate the URL after a given timeout (secdownload.timeout).

Be sure to choose a another secret than the one used in theexamples, as this is the only part of the token that is notknown to the user.

Ensure that the token is also in hexadecimal. Depending on the programming language you use, there might be no extra step for this. For instance, in PHP, the MD5 function returns the Hex value of the digest. If, however, you use a language such as Java or Python, the extra step of converting the digest into Hex is needed (see the Python example below).

If the user tries to fake the URL by choosing a random token,status 403 'Forbidden' will be sent out.

If the timeout is reached, status 410 'Gone' will besent. This used to be 408 'Request Timeout' in earlier versions.

If token and timeout are valid, the <rel-path> is appended tothe configured (secdownload.document-root) and passed to thenormal internal file transfer functionality. This might lead tostatus 200 or 404.