That sort of thing - though this requires that I know what all the attributes are. Of course it’s my config, so I do, but I’d like to be able to just say “stick all the reply attributes in here” or something. Otherwise I have to have some logic to test for existence of each one, then include each instance of it, etc. etc. If I was proxying I would not know what all the attributes are - in my use case I’m not proxying, but I could imagine it would be useful for others.
I’m not above doing a patch to rlm_rest to be able to include the request/reply/control attribute lists rather than packet->vps - assuming that that’s not a crazy bad idea for internal reasons I don’t understand.. Thoughts?
This is essentially a solved problem in v4 where we have the JSON module which can perform conversions on lists to JSON data. That combined with the data parameter allows you to create arbitrarily formatted JSON data. If you really wanted to add this to v3 I guess the easiest way to would be to copy the contents of the control and reply lists to the request list. update { request: += reply:[*] request: += control:[*] } There's unlikely to be overlap between the different sets of attributes. Changing the JSON format in v3 to support lists wouldn't really work because it'd be a breaking change. If you wanted to try out the current code in master branch and go the v4 route I'd be happy to address any issues that come up. -Arran