bug in token.c ?

[Oliver Schröder]

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.

regards,
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