Feature #1904

mod_secdownload option to include url GET parameters in md5

Added by mimbert over 10 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


I am using lighttpd secure_download to restrict access to multimedia files (images and videos) to registered members to a website. However I needed to include the get parameters in the md5 hash to protect mod_flv_streaming type of URLs (

I wrote some code to support this. The string to be hashed is:

where parameters-string is for exemple "start=1234", or "start=1234&id=4321"

The following option can be used in lighttpd config file to activate this behaviour (which is disabled by default):

secdownload.md5-params = "enable"

An exemple of a generated URL:

If a user try to alter the parameters (ie: start=0&end=120) or to remove them, mod_secdownload will return a 403 error.

I included a diff file to that issue report and I would greatly appreciate I you could consider using this patch in a future release.


securedownload.diff (2.49 KB) securedownload.diff Include URL parameters in URL mimbert, 2009-02-17 15:20

Related issues

Related to Feature #646: secdownload.path_elements supportFixed


Associated revisions

Revision afce434e (diff)
Added by gstrauss over 2 years ago

[mod_secdownload] new directives modify hash path (fixes #646, fixes #1904)

secdownload.path-segments = <number>
include only given number of path segments in hash digest calculation

secdownload.hash-querystr = "enable" | "disable"
include the query string in the hash digest calculation

"secdownload.path_elements support"
"mod_secdownload option to include url GET parameters in md5"



Updated by wolpert over 7 years ago

Is there any progress with this patch? Is this known to work? I have the same needs now...


Updated by mimbert over 7 years ago

Wolpert, I've been using this patch for 3 years now. So if they don't include it in a release, I suggest you use my diff and compile your own version...


Updated by stbuehler over 7 years ago

  • Target version set to 1.4.x
  • Missing in 1.5.x set to No

1.4.x is sort of "stable", so feature requests are not a priority. And if the target version isn't set i don't see them in the roadmap, so they get lost pretty fast :)

The patch itself looks fine apart from one detail: imho the "?" should be part of the md5 too (con->uri.query starts after the "?").


Updated by mimbert over 7 years ago

Good point. I considered the '?' as a simple separator and did not include it in the signature, so in my opinion the param should only be key1=val1&key2=val2... Furthermore the signing is done in PHP and the $_SERVER['QUERY_STRING'] doesn't include the '?'.


Updated by wolpert over 7 years ago

I could use either method for the md5 myself. I'd rather keep query params attached to the md5 the way you would a path_info param... but I have no legacy code to work with here. (FWIW, My client usage will be in Java)


Updated by gstrauss almost 3 years ago

  • Subject changed from mod_secure_download option to include url GET parameters in md5 to mod_secdownload option to include url GET parameters in md5
  • Status changed from New to Need Feedback
  • Priority changed from Normal to Low

Is this feature request still desirable?

In the intervening year, additional algorithms have been added to mod_secdownload which are more tamper resistant than MD5: HMAC-SHA1 and HMAC-SHA256

Even if using MD5, arbitrary validation could be accomplished using a FastCGI authorizer in lieu of mod_secdownload, allowing the creation of the keys to be collocated with the code which validates the keys, instead of trying to extend mod_secdownload in a variety of ways.


Updated by gstrauss almost 3 years ago

  • Related to Feature #646: secdownload.path_elements support added

Updated by gstrauss almost 3 years ago

  • Status changed from Need Feedback to Patch Pending
  • Target version changed from 1.4.x to 1.4.45

Updated by gstrauss almost 3 years ago

  • Target version changed from 1.4.45 to 1.4.46

Updated by gstrauss over 2 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom