Attention! Helicon Tech Blog has moved to www.helicontech.com/articles/

Friday, March 20, 2009

Using Helicon Ape under IIS6 (Windows Server 2003)

Hello everyone!
We are continuing to write about Helicon Ape tweaking and this article is about running our monkey on Windows 2003 Server. We've received a lot of responses from the users who haven't managed to configure Ape under IIS6. So we hope this article will give enough information to get Ape working for you.

Installation

If you still haven't downloaded Helicon Ape, please do on Helicon Ape Downloads page. Run installation and follow wizard instructions to setup Ape as you need. We want to notice that there are two types of inistallation: automatic and manual. We'll use the automatic one, cause there are no circumstances to force us do it manually. Below is the installation type window:

Please don't worry when you get the following warning:

It informs IIS6 users of necessity to perfrom specific mapping configuration. Details of this process are recounted below.
After successful Helicon Ape installation, let's look into its installation folder:

We'll give a brief explanation of some of the files in this folder as this may be useful for your further relations with Ape:
httpd.conf - server configuration, has the same meaning as in Apache. The rules put into it affect all the sites for which Ape is installed. It's worth mentioning that there are directives that may be used in server config only (e.g. VirtualHost).

smart_gzip_compression.conf - ready-to-use preset for mod_gzip and mod_cache. More info is given in the article How to enable mod_gzip compression for IIS7. Unfortunately, due to IIS6 technical restrictions mod_gzip and mod_cache modules are not available to Windows Server 2003 users.

error.log - log of debug messages. Verbosity of the log depends on the level set in LogLevel directive (debug value provides the most detailed log). If you feel that Ape is not working properly, check this log first. Name and location of error log file may be changed in ErrorLog directive.

rewrite.log - log of mod_rewrite operation. This file is really helpful when your mod_rewrite rules are doing something wrong. To see maximum details in this log please set RewriteLogLevel 9 in httpd.conf. Name and location of rewrite log file may be changed in RewriteLog directive.

Helicon.Ape.chm - that's our manual! It's worth reading, I swear;)

RegexTest.exe - mod_rewrite rules testing utility.

Helicon.Ape.Manager.exe - manager helping to configure Ape for your site without pain. Powerful text editor with autocompletion and syntax highlighting will make Ape configuration a real fun. Useful information about manager you can find here: Helicon Ape Manager - 10 helpful tips.
Other files help Helicon Ape work its miracles;)
Now let's open Helicon Ape Manager (Start->Programs->Helicon->Ape->Manager) to see default Ape settings. Click on «IIS Web Sites» in the tree to see the server config:

As you see almost all settings in httpd.conf are commented out. We don't recommend to uncomment any lines if you are not thinking of using them. That's why by default only mod_rewrite and mod_proxy are enabled - these module are the most popular ones.
After installation you may use Helicon Ape for free during 45 days. If Ape is doing well, you'll probably decide to buy it. After you perform a payment on our site you are given a license key. Open Help->About in Helicon Ape Manager and press «Register»:

Put obtained credentials into the corresponding fields and press OK.

Wildcard mapping

Now Ape is installed and registered but we haven't seen it working. As we stated above simple installation is not enough to have Ape working on IIS6. It's necessary to accomplish a ritual known as «wildcard mapping». In IIS Manager open properties for the target site or all sites («Web Sites»). In the opened dialog go to «Home Directory» tab. Then press «Configuration...» button. You'll get one more dialog where you need to press «Insert...» button for «Wildcard application maps». Now you ned to select aspnet_isapi.dll library. Default location for ASP.NET 2.0 is C:\Windows\Microsoft.NET\Framework\v2.0.50727\.
Don't forget to uncheck «Verify that file exists» check box! Here's the scheme illustrating described sequence of actions:



Ape is working
Well, all steps to make Ape working are now done. Let's check if it works anyway! Open Helicon Ape Manager and select a site for which you configured the wildcard mapping. We did it for «Default Web Site».
Pay attention that if you click on site or folder in the tree, manager opens existing or creates new .htaccess for this location (the file will be created only if you use editor and save the file).
Now we'll write the simplest rules for mod_rewrite (remember it's enabled by default?):
RewriteEngine on
RewriteRule .? - [F]
These rules will cause server to give 403 (Forbidden) response for all requests to the site. Notice that it's necessary to use RewriteEngine on directive as LoadModule directives in the server config just load Ape modules but don't enable them.

Save changes to this .htaccess (File->Save or Ctrl+S). Open browser and make request to any location inside the site you've chosen in manager (we configured Ape for «Default Web Site» that's why we have localhost in the address bar). The result should resemble this:

It's unlikely, but it may happen that you don't get the desired result. This situation is not covered in this article, so you'll need to address Troubleshooting section of our documentation. Besides, soon we'll tell you what useful information may be learned from log files.
As you remember httpd.conf has also mod_proxy module uncommented. Let's check its operation as well. Both modules are used really often, so it's vitaly important to ensure they work OK. Please delete all rules from .htaccess and add the following:
RewriteEngine on
RewriteProxy (.*) http://www.helicontech.com/$1 [L]
As you can see we use mod_rewrite directives but to enable proxy fuctionality mod_proxy module is used. So these rules actually check both modules operation.

If mod_proxy works fine, you'll get something like the following upon request to http://localhost/ape:



Limitations for IIS6
We've just made sure mod_rewrite and mod_proxy successfully work with IIS6. But not everything is flawless for this web-server. The thing is that Microsoft has completely reorganized modules interface in IIS7. That's why we've encountered certain issues trying to be good for both IIS7 and IIS6 users (though originally Helicon Ape was designed for IIS7). The vague ritual of wildcard mapping is a sacrifice made to provide support of two completely different architectures (IIS6 and 7). Compatibility chart shows what functionality is limited in IIS6 and we'll demonstrate how it shows up.
One of the modules that do not work for IIS6 is mod_headers. Click on «IIS Web Sites» in Helicon Ape Manager to open server config. Uncomment LoadModule headers_module line as shown in the picture and save changes:

Now open .htaccess where we put the rules for mod_proxy and write the following rules there:

RequestHeader set MyRequestHeader "Hello Server!"
Header set MyResponseHeader "Hello Client!"

The rules you've just written tell mod_headers to set HTTP request header with the name MyRequestHeader and value «Hello Server!», and HTTP response header with the name MyResponseHeader and value «Hello Client!».
To check whether the above rules work we need a tool that displays request/response headers. We use WFetch. And here's what it said:

Content-Length and Set-Cookie headers confirm correct operation of mod_rewrite/mod_proxy. But there's no MyRequestHeader or MyResponseHeader header. Probably mod_headers haven't fired. Let's figure out why. error.log will assist us in this.
Please open the server config again and uncomment LogLevel и ErrorLog directives as shown below:

Save changes and make one more request to the server. Now open error.log in Helicon Ape installation folder. It will contain the following lines:

The first line says that mod_proxy has executed correctly. Two subsequent lines warn you that mod_headers is not supported for IIS6. Pay attention that server hasn't returned any errors. Request was handled but no the way we wanted.

Conclusion

This article was written to prove that Helicon Ape does work (with some limitations) on Windows Server 2003. And it's really easy to configure. Hope that Ape will help you achieve desired results.
Best wishes,
HeliconTech Team.

Friday, March 13, 2009

Helicon Ape 1.1.0.15 – what risen minor gives

Hello! About two months ago our technology peacemaker, Helicon Ape, has been released. Day after day we are improving existing features and designing the new ones. Two builds have already been released and now we are going to increase our product’s minor version number because this monkey is gonna be really fancy ;)

So what new features has Ape obtained? Well, this post will shed some light on this issue.

Helicon Manager

Server variables autocompletion was added to the editor. This feature can be very helpful for mod_rewrite and mod_setenvif users. Ctrl+Space combination is used to open autocompletion form:


mod_hotlink implemented (NEW)

The module is aimed at protecting your web server from people stealing your traffic by directly linking to the content on your server. This is especially important for those having image, video, documents archives and other downloadable content.

After enabling mod_hotlink your site will work as if nothing happened, all search engines and backward links will still be valid, all user’s favorites will remain working. But if someone tries to embed your stuff directly on their site, they will only see an error message or your site’s logo. You can save tons of traffic and thus money. You can even turn these hotlinks into real visitors by redirecting hotlink request to your site’s homepage.

We also recommend you to have a look at this article: Strong hotlink protection with Helicon Ape mod_hotlink module.

mod_filter implemented (NEW)

This module provides selective filter application depending on the content type. Currently mod_hotlink, mod_gzip and mod_deflate can be managed by mod_filter directives.

mod_deflate implemented (NEW)

We’ve added mod_deflate directives support. Please note that technically mod_deflate and mod_gzip have the same compression algorithm.

mod_expires

Regular expressions support for ExpiresByType directive.

mod_setenvif

  • Extended conditions syntax implemented (AND, OR and grouping support). Now you can easily create smart conditions to control Helicon Ape modules
  • Mime and Query_String attributes support implemented
  • Server variable can be used as an attribute. Two syntaxes are possible. You may use mod_rewrite style: %{VARIABLE_NAME} or simply VARIABLE_NAME:

mod_cache and mod_gzip

Management through environment variables implemented.

Thursday, March 12, 2009

Guide: How to enable mod_gzip compression for IIS7

Hi all! In this article we will tell you how to enable mod_gzip and make it work the way you want. The basics of the module are recounted in Introduction to mod_gzip. We'll only remind that mod_gzip is used to compress response before it is sent to the client.

Having Helicon Ape installed, open httpd.conf file in Ape installation folder using Helicon Ape Manager. To be able to manage the module you should uncomment corresponding LoadModule directive, as shown on the picture:

IIS possesses its own facilities for GZIP compression. These must be disabled if you are going to use mod_gzip for these purposes. Helicon Ape has a lot more means for more flexible and fine configuring. To disable internal compression in IIS please run IIS Manager, in the tree on the left choose server or specific site. Now open 'Compression' element and put the ticks as shown below:

 
Now we are ready to start writing a simple config. Let's enable compression for all requests first. According to the docs this may be accomplished in three ways. We'll use environment variables:
SetEnv gzip
The above line does the following: enables mod_gzip, allows compression for all types of requests, applies default compression level of 6.

Easy, isn't it? "But where's the flexibility you promised?" - you wonder. Not all files may be compressed to the same extent. It's well-known for instance that text documents are more "compressable" than images. And for PNG, JPEG, GIF formats the benefit may tend to zero! And everything would be just great if the module's operation didn't take time. So why waste time to fruitlessly compress almost uncompressable files if we can simply say mod_gzip not to touch them. Let's use mod_setenvif module to disable images compression:
SetEnv gzip
SetEnvIf mime image/.* no-gzip
Much better this time, right? Yeah, better but not the best:) mod_gzip can do even more! Let's play with compression level now. The default value is 6 but maximum is 9. And sometimes the difference is noticable. As we know the text is compressed well, let's set it's compression level to 9, we'll still ignore images and everything else will be compressed by default:
SetEnv gzip
SetEnvIf mime text/.* gzip=9
SetEnvIf mime image/.* no-gzip
Another situation may be that you want to compress only specific file types. Say you want only HTML/CSS/JS to be compressed with maximum compression level:
SetEnvIf (mime text/.*) and (mime application/x-javascript) gzip=9
Note! If you previously were an Apache fan, the above syntax may surprise you. Yes, it's true - it's applicable only in Helicon Ape (for your own good). Here you may find more information on extended syntax.

But if for some reason you want your Helicon Ape config to be compatible with Apache, here the equivalent to what we've done before:
mod_gzip_on yes
mod_gzip_compression_level 9
mod_gzip_item_include mime text/.*
mod_gzip_item_include mime application/x-javascript
And the most delicious dish in the end;) We've made some kind of compilation of the most effective mod_gzip and mod_cache settings that you may use on your server as is. mod_cache is used to speed up the delivery of compressed content to the user. These two modules working together substantially improve server performance. So here's the piece that'll make you happy:
# By file extension
SetEnvIfNoCase request_uri \.mdb$ gzip=9
SetEnvIfNoCase request_uri \.bmp$ gzip cache-enable=mem
SetEnvIfNoCase request_uri \.(?:jpg|gif|png|swf|avi|rm)$ no-gzip                        

# By MIME type
SetEnvIfNoCase mime text/.* gzip=9 cache-enable=mem
SetEnvIfNoCase mime audio/wav gzip cache-enable=mem
SetEnvIfNoCase mime image/bmp gzip cache-enable=mem
SetEnvIfNoCase mime message/rfc822 gzip

SetEnvIfNoCase mime application/msword gzip
SetEnvIfNoCase mime application/postscript gzip
SetEnvIfNoCase mime application/vnd.ms-excel gzip
SetEnvIfNoCase mime application/vnd.ms-powerpoint gzip
SetEnvIfNoCase mime application/vnd.ms-works gzip
SetEnvIfNoCase mime application/x-javascript gzip cache-enable=mem
SetEnvIfNoCase mime application/x-msaccess gzip
SetEnvIfNoCase mime application/pdf gzip

# Exceptions for old browsers
#BrowserMatchNoCase \bOpera(?:\s5\.|/5) and \
#    mime application/.* no-gzip vary-agent !cache-enable
#BrowserMatchNoCase \bMozilla/4\.[67] and \
#    (mime application/.* or mime image/.*) no-gzip vary-agent !cache-enable
#BrowserMatchNoCase \bNetscape(?:6/6\.|/) and \
#    mime application/.* no-gzip vary-agent !cache-enable
#BrowserMatchNoCase \bFirefox/1 and \
#    mime application/pdf no-gzip vary-agent !cache-enable

SetEnvIfNoCase (mime text/css) or (mime image/jpeg) vary-agent
BrowserMatchNoCase \bMSIE\s[567]\. and \
    (mime text/css or mime image/jpeg) no-gzip vary-agent !cache-enable

# Vary header should be properly set for caching
Header merge Vary User-Agent env=vary-agent

# Set expiry delta for static content
# Dynamic pages should set expiry delta by oneself
Header merge Cache-Control max-age=86400 env=cache-enable
You can enable the above preset for your server by uncommenting a single line in httpd.conf:
Include smart_gzip_compression.conf
Conclusion
As you can see, not so many rules are needed to adjust mod_gzip for our needs. We also showed you some examples of Helicon Ape extended syntax, but you may as well use standard Apache-compatible one. We are trying to give you a rich set of instruments, so that you can combine them the way you want and deem necessary. But simplicity and convenience are above all.

Always yours,
HeliconTech Team

Friday, March 6, 2009

Strong hotlink protection with Helicon Ape mod_hotlink module

Hello everyone!
We are happy to inform you that Helicon Ape 1.0.0.15 and newer may boast additional functionality and especially mod_hotlink module. And for you to feel its power we offer a brief overview reinforced by real practical examples.

mod_hotlink module is aimed at protecting your web server from people stealing your traffic by directly linking to the content on your server. This is especially important for those having image, video, documents archives and other downloadable content.

After enabling mod_hotlink your site will work as if nothing happened, all search engines and backward links will still be valid, all user’s favorites will remain working. But if someone tries to embed your stuff directly on their site, they will only see an error message or your site’s logo. You can save tons of traffic and thus money. You can even turn these hotlinks into real visitors by redirecting hotlink request to your site’s homepage.

Protection methods

mod_hotlink offers three protection methods each having it's advantages and peculiarities:
LINK: This is the most comprehensive and powerful protection method. In this mode mod_hotlink edits each link to protected content on your site by adding special cryptographic signature. You specify expiration time for the signature on the expiry of which link becomes invalid (e.g. 30 minutes after it was requested). LINK method is not sensitive to HTTP Referer modifications, disabled cookies or JavaScripts in user’s browsers. mod_hotlink is capable of protecting any file types including streaming media and embedded content.
REFERER: Simply checks HTTP Referer header and rejects all requests to the protected content from unknown sites. You may use white and black lists based on Referer and User-Agent values to allow friendly sites requests and protect against some ugly hacks. This method does not require any configuration or modification to your site and is a convenient way to protect image archives.
REDIRECT: Checks Referer header value but performs a redirect to a temporary signed link instead of returning content. It may be difficult to understand the theory of this method, but the only thing you need to know is that it provides moderate protection level to preserve some embedded content that cannot be protected by REFERER method - content like PDF files, Flash and Media Player movies, audio and so on. Just as in the previous method you don’t have to change anything - just enable mod_hotlink and specify a protection folder.

Examples

Enough of theory and it's time for examples we've promised before. Following are examples for each protection method with thorough explanation.

1. Referer protection method

The task is to protect all images from hotlinking; allow referers from your own site and empty referers.
The solution using mod_rewrite is:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(?:www\.)?yourdomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F]
The same solution using mod_hotlink looks like:
<FilesMatch \.(jpg|jpeg|png|gif)$>
  HotlinkProtect / [Referer]
  HotlinkAllow Referer ^$
  HotlinkAllow Referer ^https?://(?:www\.)?yourdomain.com
</Files>
How it works:
When a browser makes a request, it passes Referer header that shows the URL of the page with the requested resource.
Say you have a page default.html on your site www.yourdomain.com and there's also a link <a href=”/img/picture.gif”>picture</a>. If you click on this link, the browser generates the following request:
GET /img/picture.gif HTTP/1.1
Host: www.yourdomain.com
Referer:  http://www.yourdomain.com/default.html
Note! If you directly put the address of the resource into the browser address bar (e.g. http://www.yourdomain.com/img/picture.gif), Referer header is not passed.
  • Referer header value is verified for specified file types, i.e. jpg|jpeg|png|gif.
  • HotlinkAllow Referer ^$ – allows access if Referer header is empty or missing.
  • HotlinkAllow Referer ^http(s)?://(www\.)?yourdomain.com – allows access if Referer header starts with your domain name.
  • All others will get "403 Forbidden" for this request.

2. Redirect protection method

Redirect method is usually used to protect .pdf and .swf files as Internet Explorer sets incorrect Referer header for such files when the user clicks "Save As…"
<FilesMatch \.(?:pdf|swf)$ >
  HotlinkSignature password
  HotlinkProtect / [Redirect]
  HotlinkAllow Referer ^$
  HotlinkAllow  Referer ^https?://(?:www\.)?yourdomain.com
</Files>
How it works:
  • The user requests the page (e.g. default.html). This page has a tag <a href="/doc/test.pdf">pdf</a>.
  • The browser requests http://www.yourdomain.com/doc/test.pdf and passes Referer http://www.yourdomain.com/default.html.
  • mod_hotlink checks the rules (given above).
  • HotlinkAllow Referer ^http(s)?://(www\.)?yourdomain.com – allows further procesing.
  • Instead of granting direct access to test.pdf mod_hotlink performs redirect to a dynamically generated address http://www.yourdomain.com/doc/90f630427786fd84/test.pdf.
  • Browser requests http://www.yourdomain.com/doc/90f630427786fd84/test.pdf.
  • mod_hotlink verifies signature validity and then grants access to test.pdf.
All this stuff is necessary to bypass noncompliance of some browsers with the standards (especially this refers to Internet Explorer) as they sometimes don't set Referer header for successive requests to the same resource.

3. Link protection method

Link protection is completely independent on Referer header. But it requires manual links correction on pages.
For this example we need the following files in the root of the site:
  • default.html
  • .htaccess
  • test.pdf
default.html page should have the following tag:
<object  data='xxxxxxxxxxxxxxxx/test.pdf' type='application/pdf' > </object>
.htaccess must be configured as follows:
SetEnv mod_hotlink
HotlinkSignature password
<Files *.pdf>
  HotlinkProtect / [Link]
</Files>
When the user requests default.html mod_hotlink replaces Xs in the tag with specifically generated sequence:
<object data='90f630427786fd84/test.pdf' type='application/pdf'> </object>
How it works:
  • The user requests the page (e.g. default.html).
  • mod_hotlink replaces xxxxxxxxxxxxxxxx in the tag with dynamically generated signature.
  • The browser finds the tag <object data='90f630427786fd84/test.pdf' type='application/pdf' > </object> and makes a subrequest http:// www.yourdomain.com/90f630427786fd84/test.pdf (no matter Referer is passed or not).
  • mod_hotlink verifies signature validity and then grants access to test.pdf.
Well, that's all for today. Hope you've got some understnding of mod_hotlink capabilities and see what you can apply them to. Looking forward to your comments after first steps with mod_hotlink. Don't give leechers a single chance!

Best regards,
HeliconTech Team

Thursday, March 5, 2009

Enabling site authentication not using Windows users

Sometimes you may want to add simple user authorization to your site, but it's unlikely or impossible to use Windows users system. In such case a suitable solution is offered by HTTP authentication/authorization system implemented in Helicon Ape mod_auth fellowship. In this article we'll show how to enable basic authentication for the part of the site not applying much efforts.

Task specification

Protect secret directory in the root of the site via basic authentication. The directory contains index.html file that is displayed upon request http://localhost/secret/. Allow access to this directory to users bill, george and barack. Set passwords for these users.

Enabling necessary modules

For this task we'll need mod_auth_basic, mod_authn_file and mod_authz_user modules. To enable them you simply need to uncomment corresponding lines in httpd.conf - Helicon Ape global configuration file:
LoadModule auth_basic_module    modules/mod_auth_basic.so
LoadModule authn_file_module    modules/mod_authn_file.so
LoadModule authz_user_module    modules/mod_authz_user.so
This may be accomplished in Helicon Ape Manager.

Editing .htaccess

In Helicon Ape Manager find and click on secret directory in IIS tree. Empty .htaccess will be created and opened for this directory. We'll add the following lines:
# Authentication type
AuthType Basic
# Name of area authentication will be used for (aka realm)
AuthName "secret area"

# Authentication provider. Here - mod_authn_file
AuthBasicProvider file
# Info for mod_authn_file - path to password file
AuthUserFile c:\inetpub\.htpasswds
# Access will be granted to all authenticated users
Require valid-user

Creating passwords file

Create a new file in Helicon Ape Manager (Ctrl+N). Run the Password generator utility: Options -> Insert User Password... (or F5). Enter user name and password with confirmation.

To paste resulting string with username and password press Ctrl+Enter. Repeat this procedure for all users (remember: bill, george and barack?). Here's what you should get:

Now save the file with the name specified in AuthUserFile directive: c:\inetpub\.htpasswds.

Testing

For testing let's put http://localhost/secret/ into the address bar. This may be done faster by right-clicking on secret folder in IIS tree (in Helicon Ape Manager) and selecting "Browse *:80 (http)".

The browser will prompt us to enter user credentials (username and password).

If the data you entered are correct, the server will give you the content of index.html page from secret directory.

Conclusion

Having performed such unsophisticated actions we have protected secret directory using basic authentication. We have created users by ourselves in c:\inetpub\.htpasswds file and you may add as many of them as you like. These users have nothing to do with Windows users. The name of authenticated user is accessible from server scripts (e.g., ASP or PHP) via AUTH_USER server variable.

Important note!

Authentication data (user name and password) are transfered through the network in non-encrypted form, so it's not really safe. Secure authentication is either basic authentication via secured http (https) or digest authentication via http.