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