Standardised JSON VP list format

[Brian Candler]

On Tue, Nov 08, 2011 at 05:18:59PM +0100, Arran Cudbard-Bell wrote:
> Regarding unlang, the format proposed is actually *more* flexible than the current unlang 'update' constructs :)

I would hope that changes in future - and if I had enough time I would try
to implement it myself (the main issue being getting my head around the two
distinct sets of operator code)

I think there could be a feature that every attribute could also identify
the list, with a default list based on the context for tidiness and
backwards compatibility.

Example 'users' file:

steve	control:Huntgroup-Name =~ "foo", reply:Framed-IP-Address =~ "."
        request:Huntgroup-Name := "bar"
        reply:Framed-Protocol := PPP

Here we would default to request: or control: in the first line, dependent
on the operator; and default to reply: for the remaining lines.

In rlm_mysql: attributes returned can have a list prefix, but similarly
default to request:/control: in authorize_check_query, and to reply: in
authorize_reply_query

In unlang:

  if (control:Huntgroup-Name =~ /foo/ && reply:Framed-IP-Address =~ /./) {
    update {
      request:Huntgroup-Name := "bar"
      reply:Service-Type = PPP
    }
  }

Some of my configs would be hugely simplified if I did this. At the moment I
have to copy attributes from the Reply list to the Request list, just so
that rlm_sql can test on their presence.

> Running the values through XLAT also exposes all kinds of additional awesomeness.

And dangers :-) But allowing that is part of the semantics of rlm_rest I
think, rather than the JSON format itself. rlm_rest could have a flag to
enable or disable this.

Personally I don't like expansions to have side-effects. If the debug level
were instead controlled by an attribute on the control: list, then you could
just return a regular update.

Regards,

Brian.