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

This begins a <Handler> clause. When using the <Handler> clause, all requests with a specific set of attributes are handled in the same way. You can configure one or more <Handler> clauses into your server, possibly with a different AuthBy authentication methods for each.
The difference between <Handler> and <Realm> is that <Handler> groups together requests based on the value of any attributes in the request, not just the user's realm as <Realm> does. That makes <Handler> clauses more powerful but they are not required as often. A common situation is that you need to distinguish between authentication methods based on the user's realm. Use <Handler> instead of <Realm> if you need to choose authentication methods based on other attribute than Realm, such as Called-Station-Id, Request-Type, or some other attribute in the incoming RADIUS request.
In <Handler checklist> the checklist expression is a list of request attributes that must all match before <Handler> is used to handle the request. The format is similar 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 matches all requests.
When Radiator looks for <Handler> to match an incoming request, it searches each <Handler> clause in the order in which they appear in your configuration file. It continues searching until <Handler> is found where every check item in the expression matches the request. If any check item does not match, it continues onto the next <Handler> until all the Handlers are exhausted. If none of the <Handler> clauses match, Access-Request is rejected and Accounting-Request is accepted.
Radiator uses the following algorithm to find the <Realm> or <Handler> to handle each request:
  1. Look for a Realm with an exact match on the realm name.
  2. Look for a matching regular expression Realm.
  3. Look for a <Realm DEFAULT>.
  4. Look at each Handler in the order they appear in the configuration file until one where all the check items match the request.
  5. Ignore the request.
It is possible to use both <Handler> and <Realm> clauses in the same configuration file but it is not recommended. Using them together may lead to complicated handler selections and behaviour.
The following example configuration uses 3 authentication methods used in different requests:
  • <AuthBy SQL>
    This used when Called-Station-Id is 662543 and Service-Type is Framed-User.
  • <AuthBy DBM>
    This is used when Called-Station-Id is 678771 and Realm is open.com.au.
  • <AuthBy RADIUS>
    This is used authenticating all the requests that do not match to the previous criteria.
<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>
All instances of the given attribute are checked, so it is possible to define a check that requires a request to contain multiple values. Here are 2 examples of multiple values, both of them are allowed:
# Request has attributes in a following order:
# OSC-Group-Identifier=A
# OSC-Group-Identifier=B

# Does match
<Handler OSC-Group-Identifier=B>
    ....
</Handler>
# Request has attributes in a following order:
# OSC-Group-Identifier=A
# OSC-Group-Identifier=B

# Does not match
<Handler OSC-Group-Identifier=B,OSC-Group-Identifier=C>
    ....
</Handler>

# Does match
<Handler OSC-Group-Identifier=B,OSC-Group-Identifier=A>
    ....
</Handler>