Standardised JSON VP list format

[Arran Cudbard-Bell]

On 10 Nov 2011, at 14:40, Brian Candler wrote:

> 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?

Yes

>  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.

Mmm no. The server sends a complete request list to the remote application,
the application can figure out what it wants to modify.

If users want to admins want to expose more than the request list they can copy the values
across...


In the reply allowing the outer JSON object to specify lists does make sense though, 
shouldn't be too hard to do for rlm_rest.

-Arran

Arran Cudbard-Bell
a.cudbardb at networkradius.com

Technical consultant and solutions architect

15 Ave. du Granier, Meylan, France
+33 4 69 66 54 50