bug in token.c ?

Oliver Schröder 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 
somthing**somethingelse**other etc.
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 
is this:

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.

Oliver Schröder

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.
>    *Why*?
>    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 mailing list