0

I have a hardlink (created with the php link() function) on my server that is named looksLikeAdirectoryButReallyIsPHPfile and it is linked to aRealDir/index.php

looksLikeAdirectoryButReallyIsPHPfile and aRealDir are in the root directory for the web server

however when I request http"//example.com/looksLikeAdirectoryButReallyIsPHPfile I get the source code and not the PHP processed result of the code.

I attempted this handler in the root directory's .htaccess file, but it doesn't do anything:

<Files "looksLikeAdirectoryButReallyIsPHPfile">
    SetHandler application/x-httpd-php
</Files>
  • 1
    FWIW, it doesn't really matter that it's a hardlink, for all intents and purposes it's identical to a normal file. In the end you just have a PHP file without the `.php` ending. – I'd be much more worried about why you are using `link()` in the first place. This might be a case of trying to solve the wrong problem with the wrong tool. Are you merely looking for *Rewrite Rules* to make your URLs pretty...?! – deceze Jul 28 '16 at 09:10
  • @deceze the objective is to prevent basic vulnerability analysis. If the .php file extension is exposed, a potential hacker knows that I am now running the PHP engine on my server. Also, rewrite rules don't allow POST data to be passed. I am trying to find a solution that allows POST requests, but doesn't give away the php engine –  Jul 28 '16 at 09:15
  • Wut? Rewrite rules are perfect for hiding "the extension" and they work with all sorts of requests. – deceze Jul 28 '16 at 19:19
  • → http://stackoverflow.com/a/20563773/476 – deceze Jul 28 '16 at 19:19
  • *Internal rewriting* does not cause redirects unless you explicitly return a 3xx status to the client. Internal rewriting is *internal* to the web server and merely affects how the request is handled *internally*. You're *really* just looking for `RewriteRule` to solve your problem and are barking up the wrong tree. – deceze Jul 29 '16 at 08:27
  • Thanks, just realized that... –  Jul 29 '16 at 08:27

0 Answers0