3.25. <Handler attribute=value,attribute=value, ....> Previous topic Parent topic Child topic Next topic

The beginning of a Handler clause. The clause continues until </Handler> is seen on a line. A Handler clause causes all requests with a specific set of attributes to be handled in the same way. You can configure one or more Handlers into your server, possibly with a different AuthBy authentication method(s) for each.
<Handler> differs from <Realm> because it can group together requests based on the value of any attribute(s) in the request, not just the user's realm. That makes Handlers much more powerful, but they are not required as often: the most common situation is that you will need to distinguish between authentication methods based on the user's realm. You may wish to use Handlers instead of Realms if you need to choose authentication methods based on, for example, Called-Station-Id, or Request-Type or some other attribute in incoming RADIUS requests.
In <Handler checklist>, the checklist expression is a list of request attributes that must all match before this Handler will be used to handle the request. The format is exactly the same as a list of check items in a user file: a list of attribute=value pairs, separated by commas. For more information, see Section 7.1. Check items.
If you omit the expression name from the <Handler> line, the clause will match all requests.
When Radiator looks for a <Handler> clause to match an incoming request, it will look at each <Handler> clause in the order in which they appear in your configuration file. It will continue looking until a <Handler> is found where every check item in the expression matches the request. If any check item does not match, it will continue onto the next Handler until all the Handlers are exhausted. If no Handlers match, Access-Requests will be rejected, and Accounting-Requests will be accepted.
Note
Radiator uses the following algorithm to find a Realm or Handler to handle each request:
  1. Look for a Realm with an exact match on the realm name
  2. If still no exact match, look for a matching regular expression Realm
  3. If still no match, look for a <Realm DEFAULT>
  4. If still no match, look at each Handler in the order they appear in the configuration file until one where all the check items match the request.
  5. If still no match, ignore (i.e. do not reply to) the request.
Mixing Handlers and Realms in the same configuration file is permissible but may lead to hard to understand handler selections, and difficult to understand behaviour.
In the (contrived) example below, all requests with Called-Station-Id of 662543 and Service-Type of Framed-User will be authenticated with SQL. All requests with Called- Station-Id of 678771 and a realm of open.com.au will be handled with a DBM, and all other requests will forwarded to another RADIUS server. Much more complicated authentication schemes are possible.
<Handler Called-Station-Id=662543,Service-Type=Framed-User>
      <AuthBy SQL>
            ......
      </AuthBy>
</Handler>
<Handler Called-Station-Id=678771,Realm=open.com.au>
      <AuthBy DBM>
            .....
      </AuthBy>
</Handler>
# Handles anything that was not handled above:
<Handler>
      <AuthBy RADIUS>
            .......
      </AuthBy>
</Handler>