Home Free download! Version & upgrade info Documentation... So, what exactly is DeLeach? Installation Getting started Registration Configuration files Trouble? Tricks and tips... How to stop bandwidth theft How to create gateway pages Notes about copyright management Spider management Browser-specific pages Content licensing FAQ About us Previous: Registration Next: Trouble?

Configuring DeLeach:

We have already seen, in the Getting Started guide, that the key to using DeLeach lies in handling polcies.

To recap, a policy is both:

• A rule which describes what kind of file access is being attempted, and
• a directory, in the website, which contains the files to be served into each policy rule.

Out of the box, depending on the version you're using, either two or three policies are defined for you. They are:

• _self: the file is being requested from inside the website,
• (In the free ediiton, only _self and _def are defined. _null is treated just the same as _def)_null: We don't have any referer information. There may be two reasons for this:
  • Somebody just typed the URL for the file into their browser. They haven't been refered.
  • The user has switched off referers in their browser.
• _def: any event not already spoken for.

You can create directories in your website with these names, move files into them, and Deleach will begin protecting you right away.

But DeLeach goes much further than this. You can add new rules to these built-in policies, you can add whole new sets of rules, and (if you're hosting multiple websites) you can create different configurations for each website.

Are there any limits to configuration?

Yes - not all the versions permit all the configurations. Each version is designed for a different application, and some applications can't use all the facilities. Here's a brief summary:

Please bear these limits in mind when you're working on your configurations.

The DeLeach configuration files:

All the configuration is done using special configuration files. All versions (except the free version) use a single, system-wide configuration file.

You define the location of the file using the DeLeach Admin console. Provided you have correctly registered your copy of DeLeach, the first tab shows the path to the config file.

Out of the box, this configuration file is placed in the same directory as the DeLeach executable. Typically it will be called profile.dlp. You can place the file anywhere you wish, and can give it any name you wish.

More specifically, it is reasonable to place the file in the website's directory. (In the executable directory, it will only be accessible to administrators. In the website directory it will be accessible to your programmers as well). In this case, the config file will not be visible through your webserver, and visitors to your website will not be able to see it.

In addition, the Enterprise Edition permits a configuration file to be placed at the root of any virtual host, which will be interpreted alongside the global configuration file. These per-site configuration files are always called profile.dlp. Again, they are not visible through your webserver.

So, to summarise:

Configuration rules:

The least you need to know:

• Your website contains a number of policies
• Policies are made of one or more rules
• Rules are made of one or more tests.

DeLeach configuration files contain the rules for creating or modifying policies. Here's a very simple example:

(Note, there are no spaces around the = sign)<rule name="_self">
   <referer> www.webgineers.co.uk </referer>
   <referer> www.the-webgineers.co.uk </referer>
</rule>

(You can define a rule for any policy, including the built-in policies. You can even define a rule for the _def policy!)

This is a useful rule for us at The Webgineers. It says that, in addition to _self's normal meaning (that is, the file is being requested from within this website), it also means that the file is being requested from one of our website's aliases. This rule says that requests from these websites will be treated in exactly the same way as requests from within this one. In effect, this rule states who my friends are.

You can see two important features:

• The rule names the policy: name="_self"
• The rule contains some tests: two <referer> clauses

Normally, a rule is triggered (and therefore activates its policy) if any of the contained tests is true. Alternatively, You can define that all the contained tests need to be true for the rule to trigger. Thus:

(The default, the opposite of selection="all" is selection="any")

<rule name="_inside" selection="all">
   <referer> internal.webgineers.co.uk </referer>
   <ip> 127.0.0.1 </ip>
</rule>

This rule states that you are regarded as "inside" your website if both the refering host is as stated, and you're actually at the machine.

More about tests:

There are four different tests you can apply in a rule. They are:

• <referer>: true, if the referer site exactly matches the name given (ignoring case):

<rule name="_allofme">
   <referer> deleach.webgineers.co.uk </referer>
   <referer> www.webgineers.co.uk </referer>
   <referer> www.the-webgineers.co.uk </referer>
</rule>

• <ip>: true if the requesting site matches the IP address given:

<rule name="_my-offices">
   <ip> 191.84.53.236 </ip>
   <ip> 82.65.89.243 </ip>
</rule>
<rule name="_blacklist">
   <ip> ... </ip>
</rule>

• <user-agent>: true if the name given appears anywhere in the user-agent string (ignoring case):

<rule name="_firefox">
   <user-agent>Mozilla</user-agent>
   <user-agent>Firefox/</user-agent>
</rule>
<rule name="_msie">
   <user-agent>MSIE</user-agent>
</rule>
<rule name="_msie-latest" selection="all">
   <user-agent>Mozilla</user-agent>
   <user-agent>MSIE 7.0</user-agent>
</rule>

• <policy>: true if the policy name given is already active (ignoring case).

<rule name="_at-my-desk" selection="all">
   <policy> _firefox </policy>
   <policy> _my_offices </policy>
</rule>

Rulesets:

There's one more level of organisation. Rules can be collected together into rulesets, like this:

<ruleset name="demo" enable="true">
   <rule name="_inside"> ... </rule>
   <rule name="_outside"> ... </rule>
</ruleset>

A ruleset is no more than a placeholder for a collection of rules. The name has no operational significance. The important part of the ruleset is the enable clause:

• When enable="true" (or equivalently, "enabled") all the contained rules are active.
• When enable="false" (or equivalently, "disabled", all the contained rules are discarded.

This permits groups of rules to be switched in and out together, for testing or versioning purposes.

Rulesets can be nested.

In summary:

• Policies are made of rules
• Rules are made of tests.
• Rules may be assembled into rulesets

How configuration files are interpreted:

Recall, when a request for a URL arrives at your web server, the corresponding file in the website's directory is served. Only if the file doesn't exist will DeLeach step in.

DeLeach will try to serve a file from one of the policy directories:

• If the required file exists in the directory, it will be served in place of the missing file, otherwise
• (Recall, a generic file is one whose name is #.ext)If a generic file exists in the policy directory, then the generic file will be served in place of the missing file, otherwise
• The server will serve a 404 error.

We have seen that DeLeach's policies are activated based on the rules that define those policies. Because of the way the rules are constructed, several policies may be activated at the same time, but DeLeach can serve only one file. How is the policy directory selected from among the active policies?

There are three, guiding principles:

• Rules have a natural order. Specifically:
  • First come the built-in rules, _self and _null
  • then any rules defined in the global configuration file, in the order in which they appear in the file,
  • then any rules defined in the per-site configuration file, if any, in the order in which they appear in the file,
  • then, finally, _def is activated.
• DeLeach will always serve a file if it can.
• Specific files are preferable to generic files

When called upon to substitute a file DeLeach does the following:

Please see our "hints and tips" pages for examples of configurations, and discussions of how they work.