Doymer Consultores

  • Increase font size
  • Default font size
  • Decrease font size
Inicio Blog Joomla! htaccess with Joomla on Windows

htaccess with Joomla on Windows

Print PDF

It is well known that in order to protect ourselves against some basic exploits many sites of internet recommend the use of the .htaccess file. But this method only works if our server is Apache based and many of us use windows servers though not IIS version 7. ¿Does that mean that we have to bow out this input filter? The reply is that we have not to and in this article we will try to offer some alternatives.

For those that serve their web pages from IIS there exist alternatives like UrlRemap included in the IIS6 resource kit, IISRewrite, UrlRewriting.Net, IIS7 RewriteModule, etc. but each one has some drawback. Either you need the .Net environment, and then ALL requests run through ASP.NET lowering the performance of your site, or they do not support regular expressions or they requiere having IIS7.

Exploring other options

Happily, the list of available options includes IIRFextlink, a free (Donationware), open source, rewrite filter for IIS that allows the use of regular expressions and has many more funtionalities. An interesting feature of IIRF is that it executes as a single process but allows different filters for your different sites in case you host many sites in the same IIS server what mekes it very efficient. And finally its author, Cheeso, attends very actively the product forum and is a very open and friendship so, though free, product support is incredibly good.

I am not speaking in this article about the inners of downloading and installing of IIRF because the instructions are quite clear in the help page that you can find hereextlink so, in this article, I will discuss about how can we use it to protect somehow our Joomla pages and how to improve or fix SEF problems. Joomla already includes an htaccess file and we will use it as a foundation to build ours.

As indicated in the IIRF documentation we need to create an iirf.ini file in the root folder of the site we want the filter service to work. As told before we will copy the Joomla htaccess file contents in this file and work with it.

We must first verify some general parameters like the status of the rewrite enginge. So include the following lines if they are missing:

RewriteEngine On
#RewriteLog c:\logs\iirf
RewriteLogLevel 3

The first line activates the rewrite engine. The second one (commented out in the former example) activates log file writing where the actions of the filter are being written as our rules are being executed. It is interesting to activate it whilst we start the service and when we modify the rule set contents both to certify that the filter is active and to show that the rules are being executed as we had planned to, and then deactivate it to avoid filling up our disk with information that we are hardly going to check afterwards.

The third line defines the amount of information that we want to feed into this file each time a user makes a request for a page of our site and the shown value is a good starting point to know if we are doing well or not.


Now we find in the original htaccess file two sections, one dealing with common exploits blocking and another about SEF. First one is perfectly well as it is and IIRF will have no trouble understanding and processing its contents. But in SEF section we will have to make some arrangements. This section as it appears in htaccess is as follows:

########## Begin - Joomla! core SEF Section
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
########## End - Joomla! core SEF Section

A problem with these lines is that IIRF does not implement already the E modifier so that the line

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

is not valid. So we have to delete it and carry the L modifier up to the previous line that now will be the last executed in that block if a match is found.

A problem about deleting this line shows if you have PHP installed as a CGI and not as a ISAPI module. The work of this line is to assign the user/password pair to the environment variable HTTP_AUTHORIZATION allowing that the authorisation mechanism of PHP works when it is installed as a CGI too by being able to fing this values in the environment. This is something that we lose if we use IIRF at least until its creator include support for modifier E. So if your PHP is executed as a CGI program you will have to reinstall it as an ISAPI module to be able to use IIRF without losing PHP authorisation.

After applying this change the section is as follows:

########## Begin - Joomla! core SEF Section
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php [L]
########## End - Joomla! core SEF Section

Other thigns we can do

If we have activated the option to generate URLs that be friendly to search engines, already known as SEF, then our URLs will be like /component/10/003/my-article or alike. These URLs are the preferred of search engines and will help your to better position you site pages. But they have the down side of limiting site structure changes. Once that they have linked the URL to the page if we change the site structure they will point to non existant pages and what was and advantage before will turn in a handicap now.

In our case one of these references was wrongly pointing to /blog/es/blog/joomla/article where the right link was /es/blog/joomla/article. This problem started when we changed the site to include other langages after having being online for some time, something that seems fairly common. Using the rewrite power of IIRF and the data from not found pages that you get from site access statistics programs, we can fix these problems. So our URLs now start with /es or /en (or whatever) and not with /blog we can use the following roule to fix it

# Capture requests that start with /blog/ and delete it
RewriteRule ^/blog/(.*)$ /$1 [NC]

You must be careful with your rules or you may delete the /blog after the language indicator too. To avoid this we anchor the search pattern to the start of the URI by means of the starting indicator ^. So only whatever starts with /blog/ will match. This means that requesting will not be affected by this rule while will be.

We can go on adapting our URLs to the new format of our site but we must take into account the recursive nature of mod_rewrite that IIRF also implement; So each time that a rule find a match and make a substitution the pointer is restarted and the sistem start over with the first rule with the data that has just been changed. Nevertheless this change is not injected into global variables at each stage, but only at the end to improve performance. So that changes exist only in the internal variable referenced by $0 macro. So if you use the original line of htaccess that uses the URI to check for index.php

RewriteCond %{REQUEST_URI} !^/index.php

this does not work this time because REQUEST_URI still contains the statring URI unmodified value not the one modified by the first rewrito. And though the solution is only an step beyond  because if we use $0 instead of %{REQUEST_URI} we will be collecting the changes we did in former loops and will work as expected. If we apply this to our ruleset we would get something like this:

# Capture requests not starting with index.php like /es/blog/joomla/article
# and add /index.php for our router to work as it might
# Ignore service folders like plugins, images, templates, components, etc.
RewriteCond $0 !^/plugins/
RewriteCond $0 !^/images/
RewriteCond $0 !^/media/
RewriteCond $0 !^/includes/
RewriteCond $0 !^/templates/
RewriteCond $0 !^/components/
RewriteCond $0 !^/modules/
RewriteCond $0 !^/administrator/
RewriteCond $0 !^/index.php
RewriteRule ^(.*) /index.php$1
# Capture wrong URLs (folders, invalid files, etc) and redirect to home
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond $0 !^/index.php
RewriteCond $0 (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php [L]

Remember, if you write open rulesets, that is those not having modifier L in the rewrite rule, you must take care of using the right input in the condictions or will enter in a loop. By default, and to avoid blocking the system, this loop is limited to 8 passes but the final result will not be what you wanted.

And in any doubt about which rules are right go first to the documentation and carefully read what it is written there. There is a lot of information condensed and reading must be detailed because there are things that are not easily seen at a first glance. You also may read the requests made by other users in the support forums and, as a last resort, make a call for help. But don't do that without first reading the manual or Cheeso will get angry (and with reasons).

Last Updated on Tuesday, 19 October 2010 15:54  


0 # Leonardo 2012-08-09 13:35
Oi, eu estou com um problema, Não Consigo usar, da erro 500
Reply | Reply with quote | Quote

Add comment

The owner of this site is not responsible of the opinions that users pour in their comments, and can or cannot agree with what they write.

Fair Play, Please

Please do not make offensive or insult-ant comments. Avoid publicity and Spam. Do not use the comments area to 'plug' your own site. Links you write may be erased. We pretend to create an open space for the authors and users to communicate.

Everyone will enjoy the right use of language, because not all are able to understand 'codified' messages SMS alike. Please do not write only with UPPER case because this is like yelling and you will probably not get attended faster only for yelling, probably the opposite.

Editing reserves

We reserve the right to not include comments that are offensive, unpleasant, that attack third parties (racists, homophobes, etc) or that have nothing to do with the site or the article.
Supplied data is private and owned by you and will not be used to start any commercial or other kind of action.

Security code

Archived Items

Powered by ArtTree