unlang.5

使用最广泛的radius的linux的源码

	if (User-Name == "bob") {
.br
		...
.br
	if (Framed-IP-Address > 127.0.0.1) {
.br
		...
.br
	if (Service-Type == Login-User) { 
.DE
.RE
.IP "strings"
.RS
Double-quoted strings are expanded by inserting the value of any
variables (see VARIABLES, below) before being evaluated.  If
the result is a number it is evaluated in a numerical context.

String length is limited by line-length, usually about 8000
characters.  A double quote character (") can be used in a string via
the normal back-slash escaping method.  ("like \\"this\\" !")
.RE
.IP 'strings'
Single-quoted strings are evaluated as-is.  Their values are not
expanded as with double-quoted strings above, and they are not
interpreted as attribute references.
.IP `strings`
Back-quoted strings are evaluated by expanding the contents of the
string, as described above for double-quoted strings.  The resulting
command given inside of the string in a sub-shell, and taking the
output as a string.  This behavior is much the same as that of Unix
shells.

Note that for security reasons, the input string is split into command
and arguments before variable expansion is done.

For performance reasons, we suggest that the use of back-quoted
strings be kept to a minimum.  Executing external programs is
relatively expensive, and executing a large number of programs for
every request can quickly use all of the CPU time in a server.  If you
believe that you need to execute many programs, we suggest finding
alternative ways to achieve the same result.  In some cases, using a
real language may be sufficient.
.IP /regex/i
These strings are valid only on the right-hand side of a comparison,
and then only when the comparison operator is "=~" or "!~".  They are
regular expressions, as implemented by the local regular expression
library on the system.  This is usually Posix regular expressions.

The trailing 'i' is optional, and indicates that the regular
expression match should be done in a case-insensitive fashion.

If the comparison operator is "=~", then parantheses in the regular
expression will define variables containing the matching text, as
described below in the VARIABLES section.
.SH VARIABLES
Run-time variables are referenced using the following syntax

.DS
	%{Variable-Name}
.DE

Note that unlike C, there is no way to declare variables, or to refer
to them outside of a string context.  All references to variables MUST
be contained inside of a double-quoted or back-quoted string.

Many potential variables are defined in the dictionaries that
accompany the server.  These definitions define only the name and
type, and do not define the value of the variable.  When the server
receives a packet, it uses the packet contents to look up entries in
the dictionary, and instantiates variables with a name taken from the
dictionaries, and a value taken from the packet contents.  This
process means that if a variable does not exist, it is usually because
it was not mentioned in a packet that the server received.

Once the variable is instantiated, it is added to an appropriate
attribute list, as described below.  In many cases, attributes and
variables are inter-changeble, and are often talked about that way.
However, variables can also refer to run-time calls to modules, which
may perform operations like SQL SELECTs, and which may return the
result as the value of the variable.
.PP
Referencing attribute lists
.RS
Attribute lists may be referenced via the following syntax

.DS
	%{<list>:Attribute-Name}
.DE

Where <list> is one of "request", "reply", "control", "proxy-request",
"proxy-reply", or "outer.request", "outer.reply", "outer.control",
"outer.proxy-request", or "outer.proxy-reply". just as with the
"update" section, above.  The "<list>:" prefix is optional, and if
omitted, is assumed to refer to the "request" list.

When a variable is encountered, the given list is examined for an
attribute of the given name.  If found, the variable reference in the
string is replaced with the value of that attribute.  Some examples are:

.DS
	%{User-Name}
.br
	%{request:User-Name} # same as above
.br
	%{reply:User-Name}
.br
	%{outer.reqest:User-Name} # from inside of a TTLS/PEAP tunnel
.DE
.RE
.PP
Results of regular expression matches
.RS
If a regular expression match has previously been performed, then the
special variable %{0} will contain a copy of the input string.  The
variables %{1} through %{8} will contain the substring matches,
starting from the left-most parantheses, and onwards.  If there are
more than 8 parantheses, the additional results will not be placed
into any variables.
.RE
.PP
Obtaining results from databases
.RS
It is useful to query a database for some information, and to use the
result in a condition.  The following syntax will call a module, pass
it the given string, and replace the variable reference with the
resulting string returned from the module.

.DS
	%{module: string ...}
.DE

The syntax of the string is module-specific.  Please read the module
documentation for additional details.
.RE
.PP
Conditional Syntax
.RS
Conditional syntax similar to that used in Unix shells may also be
used.
.IP %{%{Foo}:-bar}
If %{Foo} has a value, returns that value.
.br
Otherwise, returns literal string "bar".
.IP %{%{Foo}:-%{Bar}}
If %{Foo} has a value, returns that value.
.br
Otherwise, returns the expansion of %{Bar}.

These conditional expansions can be nested to almost any depth, such
as with %{%{One}:-%{%{Two}:-%{Three}}}
.RE
.PP
String lengths and arrays
.RS
Similar to a Unix shell, there are ways to reference string lenths,
and the second or more instance of an attribute in a list.  If you
need this functionality, we recommend using a real language.
.IP %{#string}
The number of characters in %{string}.  If %{string} is not
set, then the length is not set.

e.g. %{#Junk-junk:-foo} will yeild the string "foo".
.IP %{Attribute-Name[index]}
Reference the N'th occurance of the given attribute.  The syntax
%{<list>:Attribute-Name[index]} may also be used.  The indexes start
at zero.  This feature is NOT available for non-attribute dynamic
translations, like %{sql:...}.

For example, %{User-Name[0]} is the same as %{User-Name}

The variable %{Cisco-AVPair[2]} will reference the value of the
THIRD Cisco-AVPair attribute (if it exists) in the request packet,
.IP %{Attribute-Name[#]}
Returns the total number of attributes of that name in the relevant
attribute list.  The number will usually be between 0 and 200.

For most requests, %{request:User-Name[#]} == 1
.IP %{Attribute-Name[*]}
Expands to a single string, with the value of each array
member separated by a newline.
.IP %{#Attribute-Name[index]}
Expands to the length of the string %{Attribute-Name[index]}.
.SH ATTRIBUTES
The attribute lists described above may be edited by listing one or
more attributes in an "update" section.  Once the attributes have been
defined, they may be referenced as described above in the VARIABLES
section.

The following syntax defines attributes in an "update" section.  Each
attribute and value has to be all on one line in the configuration
file.  There is no need for commas or semi-colons after the value.

.DS
	Attribute-Name = value
.DE
.PP
Attribute names
.RS
The Attribute-Name must be a name previously defined in a dictionary.
If an undefined name is used, the server will return an error, and
will not start.
.RE
.IP Operators
The operator used to assign the value of the attribute may be one of
the following, with the given meaning.
.RS
.IP =
Add the attribute to the list, if and only if an attribute of the same
name is already present in that list.
.IP := 
Add the attribute to the list.  If any attribute of the same name is
already present in that list, its value is replaced with the value of
the current attribute.
.IP +=
Add the attribute to the tail of the list, even if attributes of the
same name are already present in the list.
.RE
.PP
Enforcement and Filtering Operators
.RS
The following operators may also be used in addition to the ones
listed above.  Their function is to perform enforcement or filtering
on attributes in a list.
.IP -=
Remove all matching attributes from the list.  Both the attribute name
and value have to match in order for the attribute to be removed from
the list.
.IP ==
Remove all non-matching attributes from the list.  Both the attribute
name and value have to match in order for the attribute to remain in
the list.

Note that this operator is very different than the '=' operator listed
above!
.IP <=
Enforce that the integer value of the attribute is less than or equal
to the value given here.  If there is no attribute of the same name in
the list, the attribute is added with the given value, is with "+=".
If an attribute in the list exists, and has value less than given
here, it's value is unchanged.  If an attribute in the list exists,
and has a value greater than given here, then that value is replaced
with the one given here.

This operator is valid only for attributes of integer type.
.IP >=
Enforce that the integer value of the attribute is greater than or
equal to the value given here.  If there is no attribute of the same
name in the list, the attribute is added with the given value, is with
"+=".  If an attribute in the list exists, and has value greater than
given here, it's value is unchanged.  If an attribute in the list
exists, and has value less than given here, then that value is
replaced with the one given here.

This operator is valid only for attributes of integer type.
.RE
.IP Values
.br
The format of the value is attribute-specific, and is usually a
string, integer, IP address, etc.  Prior to the attribute being
instantiated, the value may be expanded as described above in the DATA
TYPES section, above.  This flexibility means that, for example, you
can assign an IP address value to an attribute by specifying the IP
address directly, or by having the address returned from a database
query, or by having the address returned as the output of a program
that is executed.

When string values are finally assigned to a variable, they can have a
maximum length of 253 characters.  This limit is due in part to both
protocol and internal server requirements.  That is, the strings in
the language can be nearly 8k in length, say for a long SQL query.
However, the output of that SQL query should be no more than 253
characters in length.
.SH OTHER KEYWORDS
Other keywords in the language are taken from the names of modules
loaded by the server.  These keywords are dependent on both the
modules, and the local configuration.

Some use keywords that are defined in the default configuration file
are:
.IP fail
Cause the request to be treated as if a database failure had occurred.
.IP noop
Do nothing.  This also serves as an instruction to the configurable
failover tracking that nothing was done in the current section.
.IP ok
Instructs the server that the request was processed properly.  This
keyword can be used to over-ride earlier failures, if the local
administrator determines that the faiures are not catastrophic.
.IP reject
Causes the request to be immediately rejected
.SH MODULE RETURN CODES
When a module is called, it returns one of the following codes to
"unlang", with the following meaning.

.DS
	notfound        information was not found
.br
	noop            the module did nothing
.br
	ok              the module succeeded
.br
	updated         the module updated the request
.br
	fail            the module failed
.br
	reject          the module rejected the request
.br
	userlock        the user was locked out
.br
	invalid         the configuration was invalid
.br
	handled         the module has handled the request itself
.DE

These return codes can be tested for in a condition, as described
above in the CONDITIONS section.
.SH FILES
/etc/raddb/radiusd.conf
.SH "SEE ALSO"
.BR radiusd.conf (5),
.BR dictionary (5)
.SH AUTHOR
Alan DeKok <[e-mail]>