Standardised JSON VP list format

[Brian Candler]

On Wed, Nov 09, 2011 at 02:30:11PM +0100, Alan DeKok wrote:
>   Yeah.  It would be nice to have some kind of language describing how
> to process the two lists (current, new).  But that's hard.
> 
> > This is no worse for rlm_rest than we have today, but I'd really
> > like some way to return maybe a magic attribute which either deletes all
> > attributes, or all attributes apart from those listed in the reply, or
> > triggers a specific entry in rlm_attr_filter.
> > 
> > But this is going outside the realm of JSON formatting.
> 
>   Yes.   Suggest a syntax...

Well... modules currently return lists of <attribute> <op> <value> and I
think we should stick with that, so that this feature could be used from all
existing modules like rlm_sql and rlm_files.

Modules can set control attributes as part of the 'check' phase, since at
that point operators := = += are treated as applying to the control list.

So it could be as simple as:

steve   Huntgroup =~ "foo", Pre-Apply-Module := attr_filter.deleteall
        Tunnel-Server-Endpoint:0 := 1.2.3.4

steve
	Framed-Protocol := PPP

That is: if any control:Pre-Apply-Module attributes exist then those modules
are invoked before the packet is updated by merging in the control and reply
lists.

Some care is needed to prevent infinite recursion, and maybe this feature
needs to be enabled individually per module for security.

This does raise an additional thought I have about rlm_rest. Is it going to
be able to return updates to both control and reply lists?  The simplest
approach would be to tag attributes as control: and request:. But otherwise
it could return separate members, i.e. hash of {listname:{attribute:value}}

Also, to be a full replacement for rlm_sql I think it would need to be able
to return a sequence of control/reply lists, with the control elements
tested in turn and the first match used (unless Fall-Through = Yes is set).
That is, ignoring the details, something like

    [{
        "control":{
            "Huntgroup": [["foo", "=~"]],
            "Pre-Apply-Module:=": [["attr_filter.deleteall", ":="]]
        },
        "reply":{
            "Tunnel-Server-Endpoint": {"0" => [["1.2.3.4", ":=']]}
        }
    },
    {
        "reply":{
            "Framed-Protocol": "PPP"
        }
    }]

Using a control list in this way, where the attributes are in an unordered
JSON object, implies that it doesn't matter in which order the tests are
applied.  If you want this to be deterministic you'd have to go back to
arrays of [attr,op,value].

Or is it conceived that logic like this should exist entirely in the HTTP
server which rlm_rest submits to, which just returns one set of updates to
be applied?  I think it would be nice to be able to point to a dumb HTTP or
CouchDB server like this though.

Regards,

Brian.