3.0.x: check regex against multiple instances of attribute

Phil Mayers p.mayers at imperial.ac.uk
Mon Jul 7 20:38:12 CEST 2014


On 07/07/2014 15:09, Arran Cudbard-Bell wrote:
>
> On 7 Jul 2014, at 08:42, Alan DeKok <aland at deployingradius.com> wrote:
>
>> Phil Mayers wrote:
>>> =~ used to do this i.e. loop over the attributes, but no longer does; I
>>> think it got lost in the great unlang rewrite.
>>
>>   It should behave like the other comparison attributes.  So that's
>> either consistent and correct, or inconsistent and wrong.
>
> That was bizarre behaviour and very wrong.

Depends what you mean by "wrong". It worked that way for a *long* time 
in "users" files comparisons (may still for all I know) and was useful 
for the rare case of things like Cisco-AVPair or other multi-valued 
attributes, or simulating a loop before foreach existed (clever ordering 
of the users file and use of Fall-Through).

I submitted a patch to make unlang work the same way as "users", which 
later got superceded by the unlang changes. So it wasn't "wrong" as in 
"accidental" - it was quite intentional, at least on my part ;o)

(In fact the only reason it didn't work in unlang at the time was a 
clearly wrong use of the internal APIs that string-ified the attribute 
by name rather than reference IIRC)

In retrospect losing this doesn't trouble me; foreach works fine and is 
explcit rather than magic/implicit, which is almost always better.

But it does seem to be a common starting assumption that:

if (Attr=="val")

...would match:

Attr="foo"
Attr="val"

...and if "==" does that, they all should. Having said that, the 
semantics for the other operators, in particular ">" are troublesome.

So on balance I agree it was a weird behaviour we're better off without 
on all operators in all contexts. Maybe a warning in "debug" mode if 
someone executes a comparison against a multi-valued attribute? But TBH 
it's not a common confusion AFACIT.


More information about the Freeradius-Users mailing list