Apache .htaccess Prevent Directory Listing Tutorial
Today’s tutorial continues some of this blog’s discussions regarding a big area (of knowledge) of Apache and PHP website usage, about the use of .htacccess files we last talked about with the previous Apache .htaccess Autoprepend Autoappend Primer Tutorial as shown below. Expertise in the use of .htaccess (or by changing the httpd.conf Apache webserver configuration file) can really help improve how much the search engines acknowledge your website (ie. SEO), particularly if you can arrange for “short URLs” in this way, or by some other approach.
So today, with our local MAMP Apache web server on a Mac laptop, we discuss a method of disallowing Apache’s default behaviour for URLs that point at directories (today’s such example is the URL http://localhost:8888/CHash/), where that directory has none of the default filenames (by default, for PHP, we mean index.htm or index.html or index.php). Sometimes we would prefer not to show that directory’s listing contents, unless, perhaps, we have a tailored index.php to show our tailored directory listing:
- .htaccess contains Options -Indexes which causes a Forbidden 403 error, now, for directory URLs that are missing the default webpage filenames – yellow border above
- index.php contains code that simulates the directory listing, and is a more secure solution to this issue – green border above
A very useful link, here, is 10 useful htaccess snippets to have in your toolbox … thanks.
Please enjoy today’s tutorial.
Previous relevant Apache .htaccess Autoprepend Autoappend Primer Tutorial is shown below.
Apache .htaccess Autoprepend Autoappend Primer Tutorial
Today’s tutorial continues the discussion regarding a big area (of knowledge) of Apache and PHP website usage and would like you to reread Linux diff Primer Tutorial, way below, to get the context (of what led to the first interest) that got developed in Apache .htaccess and mod_rewrite Primer Tutorial as shown below. Expertise in the use of .htaccess (or by changing the httpd.conf Apache webserver configuration file) can really help improve how much the search engines acknowledge your website (ie. SEO), particularly if you can arrange for “short URLs” in this way, or by some other approach.
So today we discuss a method of prepending and appending PHP code acting on the HTML webpage content.
If you examine the tutorial’s picture you’ll see the Coriolis tutorial on the local MAMP webserver before and after a change. You would first think that this is just a change to index.php (see yellow directory listing), but are you sure? The times on the Firefox browser for the Before scenario and index.php listing show the same minute of the day, so it is possible that we did the Before scenario at 4:09, raced over to the editor and made the file changes for the web modification within that same minute, then waited five minutes (presumably to allow the 4:12 from Paddington to pass) before firing up the Firefox browser for the After scenario at 4:14. What are the chances of this, up against the use of .htaccess/global_prepend.php/global_append.php to use Autoprepend/Autoappend Apache httpd methods to make the change? Well, I’d say negligible, especially as the title of this tutorial is “Apache .htaccess Autoprepend Autoappend Primer Tutorial”, but also because you’ll see from the yellow listing that the times of .htaccess and global_prepend.php and global_append.php all fall between the Firefox Before and After scenarios.
Have a look at the three files that achieved it:
Do you see what’s going on? Hope so, because the implications are pretty big, as long as your Apache/PHP website allow .htaccess usage (see the AllowOverride discussion in the tutorial below). One last thing to note happens down the bottom of the picture where (hope you can see) the URL http://localhost:8888/yui_colourpicker.php shows a YUI Colour Picker. It’s a Colour Picker feeling lonely. So why is a lonely Colour Picker significant. Well, call me balmy, but am overjoyed it is alone, because http://localhost:8888/yui_colourpicker.php is down (ie. closer to the root directory) the website directory tree from http://localhost:8888/Coriolis/index.php and is not affected by the .htaccess in the Coriolis directory. The implication of this is huge for this being an aid to you using this method to control user behaviour on your website. You can have a directory (and all directories up from it on the website directory tree) where you disallow behaviours you do not want via the use of well designed .htaccess scenarios. Please bear in mind though, that there is a small performance lag caused by whatever “homemade” logic processing is involved. So this is definitely a subject you should pursue off the links of the tutorial below.
A great book to read regarding this subject, and others is Web Design for Developers by Brian P. Hogan (chapter 19 pp.273-275 talks about how you use this technique to help with mobile website design).
Previous Apache .htaccess and mod_rewrite Primer Tutorial is shown below.
Apache .htaccess and mod_rewrite Primer Tutorial
Today’s topic is a big area (of knowledge) of Apache and PHP website usage and would like you to (re?)read yesterday’s Linux diff Primer Tutorial, below, to get the context (of what led to the interest). Expertise in the use of .htaccess (or by changing the httpd.conf Apache webserver configuration file) can really help improve how much the search engines acknowledge your website (ie. SEO), particularly if you can arrange for “short URLs” in this way, or by some other approach. The optimal URL for search engines is one that:
- Has no ? nor & (very hard with dynamically generated scenarios … HTML form element method=’POST’ can help a bit)
- Has no file extension shown (ie. no .html nor .htm nor .php nor .aspx etcetera etcetera etcerera)
- Ends with /
- Contains meaningful and apt words in the URL
Think about it. If you were running a search engine with the rules above you could tell a lot about the webpage without parsing any of its contents, and not even having to do any intensive parsing of the URL.
So Apache configurations allow for the remapping of URLs without the end user having to be aware of it in any way. In this tutorial we illustrate how this works on our local Apache MAMP webserver here on this Mac.
Some good background reading here would be:
- mod_rewrite
- AllowOverride
- RewriteBase
- RewriteCond
- RewriteEngine
- RewriteRule
- URL Rewriting for Beginners Tutorial
- URL Rewriting Tutorial
Link to the MAMP scenario’s .htaccess configuration source code is downloadable here and you should rename to .htaccess (but not clobber any existing working configuration files on your system, pleeeeeeease).
Now, a bit more about the thinking. If you are a regular of this blog you will know that a lot of use is made of the file ending _GETME which is this blog’s way of providing you a download (of code like PHP, which is not accessible usually in this way). Occasionally, when trying to show you the progression of code this blog resorts to a -GETME file existing along with the older _GETME in the same place. The purpose of the .htaccess is to call diff.php when that -GETME type of file is used as a URL (will be a fairly rare occurrence) and diff.php will work out that there are both files existant, and will use the Linux diff command to show the two files, and a Linux (or unix) version of the file differences. With proper configuration all -GETME‘s could be treated this way … cute, huh?
Yesterday’s relevant Linux diff Primer Tutorial is shown below.
Linux diff Primer Tutorial
The Linux (or unix) command diff is a powerful command line tool that does file comparisons at the command line of a Linux (or unix) operating system command line. When you are coding this type of tool can be very important. You may not like to do such tasks in the command line, and have to say that a GUI (on Windows UltraEdit (text editor) is brilliant, on Mac think TextWrangler does a good job here) type of comparison works better for me, and Source Control techniques work well for many programmers, but GUI doesn’t always gel with integration, and want to show you today how the Linux diff can be incorporated into your PHP code. In saying this, am recommending extreme care with this, as its misuse can have bad implications for the whole website to be exposed to the outside world. Balancing this up against wanting to have a tool for users of this web blog to (have a more automated way to) be able to see the comparisons of files of changing code, as in yesterday’s tutorial, have decided to show the workings of this, in the rudimentary way it is used here. At the other end of diff, its output can be used by patch to make diff an even more powerful tool, and there are links about all this below.
Some good background reading here would be:
- diff (Linux or unix diff command)
- exec (as interface to use with PHP on the web)
- patch (as a way to use diff output as input to Linux or unix patch command)
So … why does the picture for this tutorial not show a Linux command line screen? Well, today we show you the power of the combination of Linux commands and the PHP way to access these commands (in our case with diff.php … the PHP exec() method). The follow up issue that tomorrow’s tutorial will address is the idea of an Apache web server configuration allowing a file “extension” to be mapped to a URL arrangement of your choosing … will save the idea here for that future tutorial, as this topic area is very big and needs the user to step back and think about, a lot, before considering.
Specifically, in diff.php (of the picture) it has a line of code …
exec(“diff ” . dirname(__FILE__) . “/one.one ” . dirname(__FILE__) . “/two.two > ” . dirname(__FILE__) . “/huh.huh”);
… to bring (Linux) diff results to the web for file comparison purposes … clicking on the picture of the tutorial shows a picture showing the link that got clicked to create the webpage of the front picture. By the way, am not showing all the code of diff.php today, and am sorry about that, but rest assured the line of code above is its crucial part.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
