bug in token.c ?
oliver.schroeder at versatel.de
Tue Jul 26 08:14:11 CEST 2011
I'm currently evaluating if we are able to replace our comercial radius
with freeradius. Our user base is very large and usernames are composed
in quite different schemes. Some usernames have a realm, some have no
realm. Some are authenticated against ldap, some against a user file,
others get proxied or tunneled etc. Some usernames have the form
My current approach is to make heavy use of the "hints" file, in which I
attach different attributes to the requests, which in turn get evaluated
via unlang. In most cases the distinction of the different cases is
based on a username/nas combination and to correctly handle the
different usernames I use regexps in the hints file. One simple example
DEFAULT User-Name =~ "(.*\.de\.de$)"
Hint := "Blacklist"
It is aimed to match User-Names like "x at whatever.de.de". In this case
the quoted string should not be interpreted but given to regcomp as it is.
Am 25.07.2011 13:53, schrieb Alan DeKok:
> Oliver Schröder wrote:
>> This piece of code removes all backslashes from the input string, which
>> gives incorrect results when parsing strings for regular expressions
>> with excaped characters.
> Do you have an example?
>> On the other hand, I'm not sure if it breaks anything else. Is there a
>> reason to remove backslashes on purpose? Or is this really a bug?
> The function gets a token from a string. The token can is *parsed*,
> which means interpreting backslashes. They're not "removed", they're
> parsed and understood.
> So yes, there's a reason to do this.
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
More information about the Freeradius-Devel