Joomla in IIS 7 : SEO Friendly URLs not working

Scenario

A Joomla website hosted in Linux server is migrated to Windows. Several compatibility issues will be reported. The rules in .htaccess file will not work in Windows Servers which will cause malfunctioning of the website. Here are the steps on how to deal with these issues.

Solution

For this to work in IIS, a web.config file should be created and the corresponding rules in .htaccess should be imported to the same file. Here is a sample web.config file. Copy the entire content.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
 <rewrite>
 <rules>
 <rule name="Security Rule" stopProcessing="true">
 <match url="^(.*)$" ignoreCase="false" />
 <conditions logicalGrouping="MatchAny">
 <add input="{QUERY_STRING}" pattern="mosConfig_[a-zA-Z_]{1,21}(=|\%3D)" ignoreCase="false" />
 <add input="{QUERY_STRING}" pattern="base64_encode.*\(.*\)" ignoreCase="false" />
 <add input="{QUERY_STRING}" pattern="(\&lt;|%3C).*script.*(\>|%3E)" />
 <add input="{QUERY_STRING}" pattern="GLOBALS(=|\[|\%[0-9A-Z]{0,2})" ignoreCase="false" />
 <add input="{QUERY_STRING}" pattern="_REQUEST(=|\[|\%[0-9A-Z]{0,2})" ignoreCase="false" />
 </conditions>
 <action type="CustomResponse" url="index.php" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
 </rule>
 <rule name="SEO Rule">
 <match url="(.*)" ignoreCase="false" />
 <conditions logicalGrouping="MatchAll">
 <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" pattern="" ignoreCase="false" />
 <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" pattern="" ignoreCase="false" />
 <add input="{URL}" negate="true" pattern="^/index.php" ignoreCase="false" />
 <add input="{URL}" pattern="(/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$" />
 </conditions>
 <action type="Rewrite" url="index.php" />
 </rule>
 </rules>
 </rewrite>
 </system.webServer>
</configuration>

So, the file web.config is ready. Now the rules in .htaccess has to be converted in accordance with IIS. In IIS6, you can make use of the ISAPI_REWRITE module. Go to http://www.isapirewrite.com/ for downloading it.

If you are having IIS7, here are the steps involved in converting those rules.

The x86 version of URL Rewrite module can be downloaded here : http://go.microsoft.com/?linkid=9722533

The x64 version of URL Rewrite module can be downloaded here : http://go.microsoft.com/?linkid=9722532

Install the module, restart the IIS manager. Choose the website in which you have to convert the rules (under Sites category). You will see the ‘URL Rewrite’ module in IIS.

Open it. Since the web.config file is already created with some predefined rules, you will see it as Inbound rules (by the Names – Security Rule and SEO Rule).

You can convert the rules in .htaccess file by accessing the ‘Import Rules’ under Inbound Rules category in the Actions pane.

Choose the .htaccess file and click Import. You will see the rules in ‘Rewrite Rules’ section and the converted rules in ‘Converted Rules’ option. Click Apply on the  Actions pane on the right hand side to save these rules to the web.config file (If a web.config file was not created as mentioned earlier, that file will be newly created). Make sure there are no conflicts in the conversion. Watch the Summary on the bottom end. There was a conflict when we did it, its shown here. In such cases, remove any unsupported rules and then click Apply.

Converting PHP to FastCGI

We have do it from Plesk control panel. If you don’t have the administrator access, you may need to contact your Administrator. Others (Gods !) read on

Select the Domain, go to Web Hosting Settings.

Scroll down to Services. Choose PHP support to run as FastCGI application.

Final Steps

Go to Joomla Administrator interface. Access Global Configuration from the main menu. Under SEO Settings, make sure the following are set to Yes

Search Engine Friendly URLs : Yes

Use Apache mod_rewrite : Yes

Done, From now your Joomla website shoule work as smooth as it were in the Linux server. Sit back and Enjoy !

Php – behind the scenes

Preface:

My previous blogs were about how we can install php in various format. Here I am trying to elaborate how php works and the steps involved  during the phase. You may wonder why such an understanding is necessary for a sysadmin job. To be honest , I was quite confused what is extensions, Zend engine and the way the total  process takes.

Thanks for the excellent post  by Abhinav Singh , now I  know  how php works

The PHP Structure

The  PHP binary consists of three layers Core PHP, Zend Engine and Extension Layer.

Core PHP :

PHP handles communication with, and bindings to, the SAPI layer (Server Application Programming Interface, also commonly used to refer to the host environment – Apache, IIS, CLI, CGI, etc).  It handles the requests, file streams, error handling and other such operations.  Due to  low level operations it performs , it is identical with a Kernel in the OS.

Zend Engine:

ZE acts as an interpreter between the user and the Core PHP. It converts the php scripts to the machine understandable format ie opcode generation and then transfer it to   CorePHP and converts the result to human readable form. ZE handles parsing a human-readable script into machine-readable tokens, and then executing those tokens within a process space. ZE also handles memory management, variable scope, and dispatching function calls

Extensions

Extensions are a bunch of functions, classes, streams made available to the PHP scripts, which can be used to perform certain tasks. For example, we need mysql extension to connect to MySQL database using PHP.

The Process

Now let as see how a php scripts work. For the sake of convenience here I assume that php is compiled as an apache module ( SAPI i.e. a Server API) using mod_php.so.

When apache is invoked , every child process will invoke a php interpreter with it.

The php  initialization takes place with the following steps

PHP begins by initializing its core subsystems. Towards the end of this start-up routine, it loads the code for each extension and calls their Module Initialization routine . This gives each extension a chance to initialize internal variables, allocate resources, register resource handlers, and register its functions with ZE, so that if a script calls one of those functions, ZE knows which code to execute. This process is called MINT or Module Initialization

Next, PHP waits for the SAPI layer to request a page to be processed. Once the  request comes in, PHP begins by asking ZE to setup an environment for the script to run in, then calls each extension’s Request Initialization function. After this the extension  gets the chance to set up specific environment variables, allocate request specific resources, or perform other tasks such as auditing  .

Once the request is initialized, ZE takes over by translating the PHP script into tokens, and finally to opcodes which it can step through and execute. Should one of these opcodes require an extension function to be called, ZE will bundle up the arguments for that function, and temporarily give over control until it completes.

After a script has finished executing, PHP calls the Request Shutdown function of each extension to perform any last minute cleanup (such as saving session variables to disk). Next, ZE performs a clean-up process (known as garbage collection) which effectively performs an  on every variable used during the previous request.

Once completed, PHP waits for the SAPI to either request another document or signal a shut down. During shutdown, PHP again cycles through each extension calling their Module Shutdown functions, and finally shuts down its own core subsystems.

I believe this should  give you some insights about how php is executed.

Further readings

http://www.supportsages.com/blog/2010/06/php-basics/

http://www.supportsages.com/blog/2010/06/php-cgi/

http://www.supportsages.com/blog/2010/06/mod_php-explained/

mod_php explained

Preface

Like in the case of all apache modules, you can either compile PHP as a static module or compile it as a dynamic module.  In the case of static module , you  can’t perform any modification for the module without recompiling the binary to which it is attached.  For eg.  you can’t add ssl support for the mod_php without re-compiling apache as a whole. And any failure in the compilation may cause downtime for the entire webserver also, including plain html support.

The advantage is that it provides a faster  performance, because the module is initialized  whenever the apache binary is started.

In the case of a dynamic mod_php installation, the necessary modifications or module additions can be done by recompiling the module alone. There is no need to recompile the Apache as the mod_php is not linked with the binary of apache.  But since the webserver loads the module on the fly, it needs to load, initialize and then execute the module.  So it can create some level of slowness while processing php pages.

How does mod_php work?

When PHP  is loaded into Apache as a module (using mod_php), each Apache process will contain an instance of mod_php or PHP interpreter also.   The interpreter comes with a bundle of libraries we enabled during compilation and each  process can make use of these libraries to process the requests. This means that the Apache process that just started  to load a simple HTML page  too will contain a PHP interpreter with all assigned libraries which inturn means resource consumption.

When the webserver gets an HTTP request. The  request header  contains the path to the requested document

e.g. access.log:    xx.xx.xx.xx – - [22/June/2010:21:14:53 -0700] “GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1″ 200 2146 “http://domain.com/info.php” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7″

1. The request will be redirected to the document root of the domain and then to the file “info.php” , if it fails then the corresponding error message will be given.

2. The info.php file is to be processed. It follows the following steps

Normally every httpd.conf file will have an entry like this

AddType application/x-httpd-php .php5 .php4 .php

AddType instructs the webserver that the files with extension .php ,.php4,.ph5 are of MIME type application/x-httpd-php. This helps the webserver to recognize files with .php are to be associated with the MIME type application/x-httpd-php

The TypesConfig directive sets the location of the MIME types configuration file. This file controls what Internet media types are sent to the client for  given file extension(s).  Sending the correct media type to the client  is important so they know how to handle the content of the file.

root@new [/usr/local/apache/conf]# cat mime.types | grep x-httpd-php
application/x-httpd-php-source          phps
application/x-httpd-php          php php3 php4 php5 php6
root@new [/usr/local/apache/conf]#

Here we can see that the Mime type to be used for files with extension .php  is application/x-httpd-php , while the file with .phps is to be mapped to the php mime type application/x-httpd-php-source .

The webserver identifies that the requested file is of Mime type x-httpd-php.

To handle or process it , the apache has to load the corresponding module. Since it is a php type , the module mod_php will be loaded and it will execute the file.

Since apache is a HTTP server. It gets the HTTP requests and answers with the HTML code.  So the mod_php will execute the commands within php flag and creates the HTML page dynamically and send it back to the client – internet browser which sent HTTP request.

Security concerns / Implications

You can see that  every request or execution of a php file through web is initiated by the webserver. So the webserver acts as the parent of every php execution through web. It imposes a great security threat. Since apache is being executed as an apache  user, all process will be owned by that user. By default  it is “nobody” or “apache”.  Let me try to explain.

If your  web application performs some operations in the db, unless that database (eg: a flat text DB) has built-in access control, you will have to make the database accessible to the “nobody” user. This means a malicious script could access and modify the database, even without a username and password.  Such can be the case with various configuration files too.  Unless you protect these directories or applications with necessary authorization techniques like .htaccess, session control etc. There is a high possibility of attack through webapplication.

Another dangerous issue is of root escalation. If the webserver has a bug, by exploiting that bug, a malicious user can gain some root privileges or escalated to root. Its quite alarming situation as an escalated apache user can do any sort of  actions without any level of authentication.

Also it is difficult to identify the script which performs the malicious activity as all php scripts will be executed as “nobody”

Since PHP applications are executed as web server user, you need to give access and write permissions for the directories wherever the application  is supposed to be working. Sometimes you may be forced to give 777 permissions and it invites lot of attacks.

The files created by php applications will be owned by user “nobody” . So the user will not be able to delete the files unless it is done through another php application. Otherwise he needs to contact the server admin to get the same.

As a security measure, we may be forced to block mails from “nobody” users . But it can create mails generated from php applications being blocked in the server. Various php applications widely used for spamming . So some servers are configured to block mails from nobody users. This creates inconvenience to users.

Further Readings:

http://www.supportsages.com/blog/2010/06/php-behind-the-scenes/

http://www.supportsages.com/blog/2010/06/php-basics/

http://www.supportsages.com/blog/2010/06/mod_php-explained/

The basics of PHP – A must read for System Admin

What is PHP?

PHP is similar to many other scripting languages like perl, python etc. But unlike perl and python what makes it stand apart is, its adaptability and power to be used as both command line and server side scripting.

I shall try to explain you the difference by executing the same file on different modes. Don’t expect too much from this post.

Command Line (CLI)

PHP Command Line Interface or PHP CLI  as the name implies,  is a way of using PHP in the system command line, like below.

In other words when the SAPI ( Server API) is “Command Line Interface” as you see above php-cli acts as a connector between underlying php binary and the command/script which invokes php from shell. This enables processing of the scripts which require php functions and provide the result after execution of the script. The advantage is that it doesn’t require a browser or webserver  for the execution. It simply requires a PHP parser ie PHP_CLI. This type of usage is ideal for scripts regularly executed using cron (on *nix or Linux) or Task Scheduler (on Windows). These scripts can also be used for simple text processing tasks. (Okay even image processing tasks )

PHP CLI is available on all popular operating systems. The first step we need to ensure is that the CLI SAPI is installed. For this locate php binary path and execute the command as given below

The result ensures that the php-cli module is installed. Now let us  see, how to make it work in a shell. The first thing is to identify the exact path on which php  binary is present. I assume that its /usr/local/bin/php.

Now create the test file info.php with the contents as shown below. You can use your favourite editor for this.

Execute the  file from the shell using the command line or shell. If you intent to use it in a cron specify the binary path (interpreter) as the first entry of file .

/usr/local/bin/php info.php

Then the out put will be  of the following  format

You can see the Application Programming Interface (API) for this script by checking the variable Server API. In the above test, it is shown as Command Line Interface. The value gets changed according to the mode of usage or execution.

As I mentioned above the php binary was  invoked  by the php-cli interpreter. Once php binary executed the query, the result was returned to the SAPI  ie php-cli, it then passed the results to the command line.

Why do we use it?

Its a quite handy option to create cron jobs. Some times we may need to perform some sort of updates or script execution periodically. If we set  a cron job for this using php, the php-cli option is quite useful.

Server-side scripting

PHP is extensively used for creating dynamic Web pages. You create pages with PHP and HTML. When a visitor opens the page, the server processes the PHP commands and then sends the results to the visitor’s browser along with the static HTML pages. PHP code is embedded into the HTML source document and interpreted by a web server with a PHP processor module, which generates the web page document.

So the minimum requirement for here are the following ones

1.  Web browser ( client side)

2.  Web server

3.   The PHP parser :  which connects the webserver with the underlying php installation.

Illustration :

Now lets us, take the same example. Here I am trying to access the page through a web browser. Let us see how the result looks like

Here , you can see the difference. In the first case when I executed the same file from shell  I got the output without any format. Now the same result is shown as an HTML page.  So let us see  how the conversion takes pace.

The webserver is  connected to the php with the help of “Server API” . This is called PHP parser  it is either CGI or Server Module like apache, litespeed etc. You can see  it is “CGI” here, but it can vary according the mod of installation and webserver it uses. Common values are FastCGI/CGI , Litespeed API, Apache etc

Once the HTTP  / Web server gets the request for the page with php , it calls PHP interpreter to generate HTML. Then this HTML is returned to the client – internet browser which sent the HTTP request.

I believe you might got some ideas how it works or differs . I shall try to give  the difference between CGI and a server module on another post

Server API (SAPI)

PHP is meant  to work on all platforms. So it is essential that it should work with different types of webservers as well.   Every version of  php comes with a set of Binaries to connect php with various webservers and it is known as SAPI.  During configuration of php, we  need to give corresponding options for the webserver to which the interpreter is to be enabled. Once the php is compiled and installed , the corresponding SAPI  will be activated. So every communication between the webserver and PHP will be interpreted  using the corresponding SAPI module enabled.

Apache may use “Apache Handler” while LiteSpeed webserver use “LiteSpeed API” as the SAPI.

Extensions

Being a powerful language which can perform various levels of operation,  PHP needs to utilize various functions and libraries installed on the server. For example GD libraries are required for a php script which performs image manipulations. While a shopping cart or such applications require db connectivity to be enabled.  Like in the case of SAPI a lot of such connectors are shipped along with PHP.  To extend the functionality of php, we enable the necessary libraries while configuring the application using “–with”  option.

You can create your own php extensions and php modules and compile them also.  Again, we will have a discussion about it later.

Recommended readings:

http://www.supportsages.com/blog/2010/06/php-behind-the-scenes/

http://www.supportsages.com/blog/2010/06/mod_php-explained/

http://www.supportsages.com/blog/2010/06/php-cgi/