Re: Initial support of Multi Valued Attributes operators

25 Mar 2013

      On Mon, Mar 25, 2013 at 05:50:26PM +0100, Olivier Beytrison wrote:
...
I've sent a pull request to add the initial support of MVA operators.
This add 4 new operators to perform basic comparison with multivalued
attributes
* |== At least one attribute should equal the value
* &== All attributes should equal the value
* |=~ At least one attribute should match the regular expression
* &=~ All attributes should match the regular expression
The allowed syntax are
attribute-name &==/|== "double quoted string with xlat expansion"
attribute-name &==/|== 'single quoted string for a fixed value'
attribute-name &=~/|=~ /regular expression/flag
How do you specify which list to search for the attribute - i.e. request,
reply, or control?

With a single-valued attribute I would do a string expansion:

  if ("%{control:Tmp-String-0}" =~ /foo/) { ...

But that won't work here unless the &=~ operator expands the LHS multiple
times (and then you get into problems if a string contains multiple
expansions)

I don't think freeradius will currently let you select the list directly:

  if (control:Tmp-String-0 =~ /foo/) { ...   nope

but if we could do that, the problem goes away. Taking this idea further, I
would very much like to be able to return attribute names from rlm_sql which
specify the list:

  insert into radgroupcheck (attribute, op, value) values (
      "reply:Framed-IP-Address", "=~", "^192\\.168\\."
  );

That would let me check the reply attributes already built up, at the
moment I have to copy specific attributes from the reply to the request list
just so they can be checked in rlm_sql.

Another idea along these lines:

  update {
    control:Tmp-String-1 += "bar"
    reply:Reply-Message += "Wibble"
  }

and finally:

  update {
    /* copy _all_ instances of the attribute to another attribute */
    reply:Reply-Message ++= control:Tmp-String-0
  }

To implement this, perhaps struct value_pair would get an extra member
identifying the list that the attribute relates to (where 0/null would mean
"the default list in this context")

But I think you're probably not proposing such a wholesale change as this
:-)

Regards,

Brian.

Re: Initial support of Multi Valued Attributes operators

Brian Candler