Using Apache to changing the file's name

[NotionCommotion]

Can Apache change the name of the served file?

For example, if file /var/www/html/someDirectory/myRealFile exists on the server, and I access http://example.com/myRealFile?name=filesAlias, I wish to return myRealFile, but call it filesAlias. If ?name=filesAlias isn't included in the URL, ideally I would like to return nothing, but I am okay returning the file with it's real name (myRealFile). I wish this rule to apply for all files in /var/www/html/someDirectory/.

Thank you

[aakk9999]

For the request http://example.com/myRealFile?name=filesAlias you will want to implement external redirect (301) to http://example.com/filesAlias

For request http://example.com/filesAlias you will then need to implement internal rewrite to http://example.com/myRealFile?name=filesAlias

In the first instance the URL in browser address bar will change to filesAlias.
In the second instance the fileAlias URL will remain in browser address bar but the content will be served from myRealFile.

[lucy24]

Can Apache change the name of the served file?

Short answer: no. As a user it may seem as if that's what is happening, because you request an URL and the browser's address bar ends up saying something different. But the only thing Apache can do is tell the browser to make a fresh request; that's the new URL you see.

It sounds as if what you're really asking about is the redirect-to-rewrite two-step, which has been covered in-- at a rough estimate-- eighty thousand threads in this subforum. It works like this:

--user requests long icky URL, probably with query string, from some earlier version of the site's URL structure
--user's browser is instructed to make a fresh request for a short pretty URL. This can either happen directly in Apache, or via a php script, depending on how straightforward the old name : new name relationship is
--when server receives a request for the new pretty URL, it secretly serves content from some other location. It might even be the identical location as the old ugly URL ("/complicated-stuff-here.php?query=something&morequery=otherthing"); the user doesn't see this part. This, too, can happen either in Apache or behind the scenes in php, depending on complicatedness.

[NotionCommotion]

Thank you aakk999 and lucy,

Let me elaborate on what I am trying to do. Some of it is PHP related, but I do not need help on that part.

User clicks on a link such as <a href="index.php?task=displayDocument&amp;id=3060219f7885f7544da0ed3d9609a440">realFileName.pdf</a>.

PHP first confirms the user is authorized to download the document.

If so, PHP then creates a symbolic link /var/www/html/documents/3060219f7885f7544da0ed3d9609a440 which points to /var/www/private/3060219f7885f7544da0ed3d9609a440.

PHP then get's the file's alias name (realFileName.pdf) from the database and redirects to the newly created location by using header("Location http://example.com/3060219f7885f7544da0ed3d9609a440?name=realFileName.pdf"); If necessary, I could also include the file mime type in the URL.

Apache then downloads the file 3060219f7885f7544da0ed3d9609a440 to the user as realFileName.pdf, and they can either open it or save it using their typical browser interface.

Periodically, the symbolic links are deleted using a cron job or some other strategy.

It would be easier to name the symbolic link "realFileName.pdf" instead of "3060219f7885f7544da0ed3d9609a440", however, this would allow a bad guy to attempt to guess typical names and access them before they get deleted.

Make any sense? Previously, I was using PHP to directly download the file, however, this is causing a bit of havoc on large files (100M).

[lucy24]

User clicks on a link

<snip>

PHP then gets the file's alias name (realFileName.pdf) from the database and redirects to the newly created location

Why doesn't the link point to the desired URL in the first place? Or did you mean "rewrites"?

this would allow a bad guy to attempt to guess typical names and access them before they get deleted

If it's a security issue, it would be better to handle it as such, by requiring some type of authentication. Security-through-obscurity has its uses, but it's certainly not the right approach for all situations.

If, on the other hand, there is rewriting involved, then you can easily intercept requests for the real-but-concealed name (RewriteCond looking at %{THE_REQUEST}). Normally it's done by redirecting to the pretty name. But if the real name has never been visible anywhere, you could perfectly well just deny access to anyone asking for the file by its real name. Remember to poke a hole for yourself!

[NotionCommotion]

Why doesn't the link point to the desired URL in the first place? Or did you mean "rewrites"?

It doesn't at first, but only does after the PHP redirects (my original post left out half the story and I am sure was misleading). It is PHP which redirects, and not Apache.

If it's a security issue, it would be better to handle it as such, by requiring some type of authentication. Security-through-obscurity has its uses, but it's certainly not the right approach for all situations.

Yes, it is a security issue, and yes, I agree Security-through-obscurity is not my best approach. But how do I provide security for this scenario? Requiring the user to authenticate the application script first and then authenticate an Apache log-in second is not an option. How do I allow the user to authenticate once in the application, and then be authorized to download files from the Apache server without having to re-authenticate?