FastCGI, PHP, Symfony2 with basic auth not working

Just had a little issue that seams to be common in the web. Got a new server with Plesk 11 (sorry for that) and it took me nearly a day to get it working and setup for capifony deployment of Symfony2 projects.

The typical issues with not correctly set access rights for the root directory of the project (should be 755), manually editing of parameters.ini and other stuff was ok. But what nearly killed me was that my Plesk installation always returned a 503 when running PHP as apache module. FastCGI was default and seemed to be working, so I went with this.

Unfortunately this did not work with the admin interface that was running in a “virtual” subdirectory. It was not possible to login. In the background it is using the default, simple, boring and potentially unsecure basic authentification.

Did you know that there is a problem with FastCGI, Symfony2 and basic authentification? I did not, but know I know. It is fixed in the current release (2.0.16) – which is good. But unfortunately there is a RewriteRule that has to be written inside your web/.htaccess. Check the comment in src/symfony/src/Symfony/Component/HttpFoundation/ServerBag.php:

* php-cgi under Apache does not pass HTTP Basic user/pass to PHP by default
* For this workaround to work, add this line to your .htaccess file:
* RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
*
* A sample .htaccess file:
* RewriteEngine On
* RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Unfortunately, I tried a different line that was written in the ticket above:

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

This did not work, but resulted in 401 results for all requests. Just remove the ,l which means that this .htaccess file will be left.

So if you are running a Symfony2 project with FastCGI, add this line to your web/.htaccess file:

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

Add a trailing slash to requested urls

Description of the problem

Some search engines remove the trailing slash from urls that look like directories – e.g. Yahoo does it. But – it could result into duplicated content problems when the same page content is accessible under different urls. Apache gives some more information in the Apache Server FAQ.

Let’s have a look at an example: enarion.net/google/ is indexed in Yahoo as enarion.net/google – which would result in two urls with the same content.

Solution

The solution was to create a .htaccess rewrite rule that adds the trailing slashes to these urls.

Example – redirect all urls that doesn’t have a trailing slash to urls with a trailing slash

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !example.php
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://domain.com/$1/ [L,R=301]

Explanation of this add trailing slash .htaccess rewrite rule

The first line tells Apache that this is code for the rewrite engine of the mod_rewrite module of Apache.
The 2nd line sets the current directory as page root. But the interesting part is following now:

RewriteCond %{REQUEST_FILENAME} !-f makes shure that files that are existing will not get a slash added. You shouldn’t do the same with directories since this would exlude the rewrite behaviour for existing directories.

The line RewriteCond %{REQUEST_URI} !example.php exludes a sample url that shouldn’t be rewritten. This is just an example – if you don’t have any file or url that shouldn’t be rewritten, remove this line.

The condition RewriteCond %{REQUEST_URI} !(.*)/$ finally fires when a urls doesn’t contain a trailing slash – this is all what we want. Now we need to redirect these url with the trailing slash:

RewriteRule ^(.*)$ http://domain.com/$1/ [L,R=301] does the 301 redirect to the url with the trailing slash appended for us. You should replace domain.com with your url. Make shure that you stick with the right domain name; if unshure, have a look at this article.

Redirect website to /index.php

Description of the problem

You have a website with the name domain.com – and you want to redirect all incomming urls that are going to domain.com/ to domain.com/index.php

Solution

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_URI} ^$
RewriteCond %{HTTP_HOST} ^domain.com$
RewriteRule ^$ http://domain.com/index.php [L,R=301]

Enable mod_rewrite on SuSE Linux

Description of the problem

By default, SuSE doesn’t enable the mod_rewrite rewrite module. It’s installed, but not enabled.
Follow these steps to install it.

Solution – enable mod_rewrite on SuSE linux

  1. Edit the file /etc/sysconfig/apache2as root:
    1. search for APACHE_MODULES, you should find a line like this
      APACHE_MODULES="suexec access actions alias auth auth_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif userdir ssl php4"
    2. Add rewrite to the content in the list between the “
    3. Save the changes and quit
  2. run SuSEconfig to update the apache configuration files
  3. run /etc/init.d/apache2 restart to restart the Apache server

Now, the mod_rewrite is enabled and integrated.

Check if mod_rewrite is installed and integrated in Apache

You can check this e.g. with the following php file. Create a file in your document root of your webserver (default on SuSE: /srv/www/htdocs) and copy the following content into this file:

<?php phpinfo(); ?>

When you view this file with your browser, search for rewrite – you should find one entry. If not – check if you did all steps 1 to 3.

Test .htaccess rewrite rule on SuSE linux Apache

The next step is to create an initial .htaccess rewrite rule to test if it’s working now. Create a file .htaccess in your document root (default on SuSE: /srv/www/htdocs) with the following content:

Options +FollowSymlinks
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule user/(.*)$ /user.php?user=$1
</IfModule>

This is a simple rule that redirects all urls with the format user/something to the script /user.php with the something as parameter user. The IfModule prevents Apache errors when mod_rewrite should disappear.

If this doesn’t work – there is another pitfall of the default SuSE Apache installation: you’re not allowed to create custom .htaccess files! So – lets enable them

Enable custom Apache .htaccess mod_rewrite files on SuSE linux

  1. Edit the file /etc/apache2/default-server.confwith your prefered editor
    1. Search for AllowOverride – it should be below the line <Directory "/srv/www/htdocs">
    2. Change AllowOverride None to AllowOverride All – this will allow custom .htaccess rewrite rules
    3. Save your changes and exit
  2. run SuSEconfig to update the apache configuration files
  3. run /etc/init.d/apache2 restart to restart the Apache server

That’s all, now you can test the .htaccess rewrite rule again and it will work.

Migrate domains

How can I migrate domain content with .htaccess?

Description of the problem:

You have an old website that is accessible under olddomain.com and you have a new website that is accessible under newdomain.com . Copying the content of the old website to the new website is the first step – but what comes after that?
You should do a 301 moved permanently redirect from the old domain to the new domain – which is easy and has some advantages:

  • Users will automatically be redirected to the new domain – you don’t have to inform them.
  • Also search engines will be redirected to the new domain – and all related information will be moved to the new domain (but this might take some time).
  • Google’s PageRankTM will be transfered to the new domain, also other internal information that is being used to set the position of pages in the search engine result pages (serp’s) – like TrustRank .

Solution:

Do a 301 redirect for all http requests that are going to the old domain.

Example 1 – Redirect from olddomain.com to www.newdomain.com

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !newdomain.com$ [NC]
RewriteRule ^(.*)$ http://www.newdomain.com/$1 [L,R=301]

This is useful when you use www.newdomain.com as your new domain name (see also this article about redirecting www and non-www domains). If not – use the code of example 2.

Example 2 – Redirect from olddomain.com to newdomain.com

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !newdomain.com$ [NC]
RewriteRule ^(.*)$ http://newdomain.com/$1 [L,R=301]

Explanation of the .htaccess 301 redirect

What does this code above do?

Let’s have a look at the example 1 – Redirect olddomain.com to www.newdomain.com. The first two lines just say apache to handle the current directory and start the rewrite module.

The next line RewriteCond %{HTTP_HOST} !newdomain.com$ specifies that the next rule only fires when the http host (that means the domain of the queried url) is not (- specified with the “!”) newdomain.com. The $ means that the host ends with newdomain.com – and the result isĀ  that all pages from newdomain.com will trigger the following rewrite rule. Combined with the inversive “!” is the result every host that is not newdomain.com will be redirected to this domain. The [NC] specifies that the http host is case insensitive.
The escapes the “.” – becaues this is a special character (normally, the dot (.) means that one character is unspecified).

The next – and final – line describes the action that should be executed: RewriteRule ^(.*)$ http://www.newdomain.com/$1 [L,R=301]. The ^(.*)$ is a little magic trick. Can you remember the meaning of the dot? If not – this can be any character(but only one). So .* means that you can have a lot of characters, not only one. This is what we need – because this ^(.*)$ contains the requested url, without the domain. The next part http://www.newdomain.com/$1 describes the target of the rewrite rule – this is our “final”, used domain name, where $1 contains the content of the (.*). The next part is also important, since it does the 301 redirect for us automatically: [L,R=301]. L means this is the last rule in this run – so after this rewrite the webserver will return a result. The R=301 means that the webserver returns a 301 moved permanently to the requesting browser or search engine.