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@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