Lists other than request in rlm_rest

[Arran Cudbard-Bell]

> On Jan 14, 2021, at 9:48 PM, Nathan Ward <lists+freeradius at daork.net> wrote:
> 
>> 
>> 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..

You might struggle to meet that with the current dynamic language modules.  Python is basically single threaded because of the GIL.  Python, Perl, Ruby etc all do complete conversions of the pair lists to/from language specific types.

I'm currently working on the python module in v4 to do just in time conversions between our boxed value format and Python's, which'll mean we don't waste CPU time converting values that'll never be used.  We may even be able to bypass the GIL and get everything running async, not sure yet.

>> 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 :-)

Yep that should work.

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

OK.

-Arran

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20210116/59f5424c/attachment.sig>