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 := 1.2.3.4 Tunnel-Server-Endpoint:1 := 5.6.7.8
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.2.3.4", "1"=>"5.6.7.8"} }
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.