签名URL vs通过脚本提供服务图像或文件

Signed URLs are paths like below, is that the correct name for those?

    http://mydomain.tld/<randomhash>.<extension>

They mostly protect access to an image and are often only available a certain amount of time. If you know the path and filename, you get access. This seems to be acceptable user access restriction for many webmail and other web application and it seems to be a common pattern.

Alternatively you could serve files or images through a script that checks access for each request, which allows tracking and user credential check on each access as described in here: Serve image with PHP script vs direct loading an image

So the trade of between the two would be, and here I would like to know if that is complete or if there is more to consider:

• signed urls need to be generated, served, discarded after t
• the longer t the more insecure
• the shorter the path the more insecure
• even when served via https sniffing the url gives anyone access during timeout of t
• access after generation is

While serving through php has the issues:

• each time accessed generating load on script engine checking user and serving image, not allowing web server a direct file path access

What would be the better approach in general? If that cannot be said, which other perspectives/issues are to be considered?

Using PHP (or any other language) is a good option here with no much overhead. What I would do:

• using Nginx or other webserver with X-forward capabilities (see e.g. mod_xsendfile on Apache)
• using the hash in GET parameter not be able to sniffed on a https channel (e.g.: http://mydomain.tld/image?hash=<randomhash>)
• on page load PHP can check if the given hash is right (even without a database with a simple file_exists call to the <hash>.png/jpeg/etc.) and give back the required headers with the X-forwarded image
• delete/remove unneeded images from protected folder after duration of time