Lists other than request in rlm_rest

[Nathan Ward]

> On 12/01/2021, at 11:04 PM, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
> 
>> 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.

Got it - good to hear there’s some tools coming to do this.
I’m also pondering python or perl or ruby or something to give me a tmp-string-x of JSON which I can stick in to the data param of a rest instance. We see about a thousand PPS at peak so should be tolerable performance..

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

I guess if I’m doing this in post-auth right before I send the packet, it doesn’t matter if I have weird stuff in the request.. certainly a bit weird though.. Interesting idea, thanks!

I think there’s a variant here to avoid mashing attributes together, something like:

rest_request
update {
  request:[*] !* ANY
  request: += reply[*]
}
rest_reply
update {
  request:[*] !* ANY
  request: += control[*]
}
rest_ control

It means 3 HTTP requests, but means clear separation between which attributes are which.. I’ve got some things to test :-)

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

Ahh yep! Thanks for the offer - I think in my situation that’s going to be a bit of a hard sell, as that would mean V4 on front end RADIUS servers which if they break means customers call up - the usual concerns about beta code in production :-)
It would be possible if I only cared about accounting as I could do that on a backend server with a buffered relay thing - but that doesn’t help me with auth logging.

Having said that, I will give it a test to see if it works for my use case, so when v4 is released we can clean up whatever solution I come up with in the mean time.

--
Nathan Ward