> I have some (strong) requirements like to not modify the application
> code or to do as few changes in the platform's
> configuration/architecture as possible. Thus I'm using Igor's example
> that seemed to me the best choice for migration from Lighttpd to Nginx.
That link includes a (lighttpd) 32-byte "hex-ascii" md5sum representation.
nginx's http_secure_link_module uses a 22-byte base64 encoded md5sum
You can't convert the one into the other using just nginx configuration.
If you want to use http_secure_link_module, you will have to modify the
application code, or modify the http_secure_link_module code, or, maybe,
try using an embedded interpreter within the nginx config to massage
the url and issue a rewrite or redirect.
That last "maybe" option also counts as coding.
Not thought through properly, of course, but could it work if your
"/get" location calculated the nginx equivalent of the 32-byte string,
and then rewrote or redirected to another location, which was handled
normally by http_secure_link_module?
You'ld also have to worry about the "time" string -- you could recalculate
it in the same way, but since it is involved in the md5sum calculation,
it wouldn't work trivially. So that looks like a "no".
> As far as I understand I got a "403" everytime I'm trying to validate
> the URL. That means $secure_link is empty and I don't know why... Of
It's because the (representation of the) hash is incorrect. 32 vs
> It will be (really) better if can keep my actual link format with the
> expiration time given in hex not in epoch but If there is no other
> solution, I will change the application's code.
To use the vanilla nginx http_secure_link_module, your old links will
be broken, and you'll have to change the application's code.
Unless there's something major I've missed.
Good luck with it,
Francis Daly email@example.com