Standardised JSON VP list format

Alan DeKok aland at
Wed Nov 9 14:30:11 CET 2011

Brian Candler wrote:
> As for tags, the first option which springs to mind is to put them in the
> attribute label, as they are in FreeRadius today.

  I'd really like to avoid that.  It makes it much more difficult to
handle attributes.

> However with tags, the update operators don't behave how I'd expect.  If I
> write
>     Tunnel-Server-Endpoint:0 :=
>     Tunnel-Server-Endpoint:1 :=
> then the second := erases all previous instances of Tunnel-Server-Endpoint. 
> The tag behaves not as part of the attribute, but as part of the value
> (which in fact it is).

  Yes, that is a problem.

> A more convenient way to handle tags would be as object keys:
> {
>   "Tunnel-Server-Endpoint": {"0"=>"", "1"=>""}
> }

  That might be better.

> Final point: if you are returning a bundle of attributes, currently these
> are always *merged* into the reply packet.  You can delete individual
> attributes using -= or !* operators, but there is no way to say "replace the
> entire reply list built so far" without invoking something like attr_filter
> in unlang.

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

  Alan DeKok.

More information about the Freeradius-Devel mailing list