[defect]: RLM_REST JSON body for octets values

[levide]

What type of defect/bug is this?

Unexpected behaviour (obvious or verified by project member)

How can the issue be reproduced?

In
https://github.com/FreeRADIUS/freeradius-server/blob/be1ec67a48e4cb7769f8ae55760d5b5ba33c1a13/src/lib/json/json.c#L222C7-L222C21

case FR_TYPE_OCTETS:
		return json_object_new_string_len((char const *)data->vb_octets, data->vb_length);

present as string and in request render as
"State":{"type":"octets","value":["?@\u0007?\u0000\u0000\u0000\u0003?\u0016??"]},

maybee need to present octets values in JSON as HEX?

Log output from the FreeRADIUS daemon

Fri Jan 26 07:22:49 2024: (7)      rest - Connect timeout is 3s, request timeout is 4s
Fri Jan 26 07:22:49 2024: (7)      rest - Adding custom headers:
Fri Jan 26 07:22:49 2024: (7)      rest -   X-FreeRADIUS-Section: authorize
Fri Jan 26 07:22:49 2024: (7)      rest -   X-FreeRADIUS-Server: tacacs
Fri Jan 26 07:22:49 2024: (7)      rest - Request body content-type will be "application/json"
Fri Jan 26 07:22:49 2024: (7)      rest - JSON Data: {"Packet-Body-Type":{"type":"uint8","value":["Continue"]},"User-Message":{"type":"string","value":["test"]},"Data":{"type":"octets","value":[""]},"Authentication-Continue-Flags":{"type":"uint8","value":["Unset"]},"Packet-Type":{"type":"uint32","value":["Authentication-Continue"]},"State":{"type":"octets","value":["?@\u0007?\u0000\u0000\u0000\u0003?\u0016??"]},"Client-Port":{"type":"string","value":["tty1"]},"Remote-Address":{"type":"string","value":["192.168.30.90"]},"Privilege-Level":{"type":"uint8","value":["User"]},"Authentication-Type":{"type":"uint8","value":["ASCII"]},"User-Name":{"type":"string","value":["test"]}}
Fri Jan 26 07:22:49 2024: (7)      rest - Returning 628 bytes of JSON data
Fri Jan 26 07:22:49 2024: (7)      rest - Content-Length will be 628 bytes
Fri Jan 26 07:22:49 2024: multi-handle 0x55f7d2432e10 will need servicing in 0 ms

Relevant log output from client utilities

No response

Backtrace from LLDB or GDB

No response

[alandekok]

I suspect it's better to use hex encoding. But the problem there is that json doesn't have data types. So hex strings will still need to be double quoted.

[levide]

yes, but now JSON contains unexpected characters in the string and JSON is not valid

[alandekok]

OK. So octets is preferable.

[arr2036]

Shouldn't be presented as hex, it's using JSON escape sequences. Maybe some chars aren't being handled correctly?

[arr2036]

Hex really isn't correct. If you use json escape sequences the string you get out of the json decoder is the binary data. If you use hex/base64 there's a manual step for decoding.

[arr2036]

Checking v4, we now use the json-c functions. So this is very likely to be <= v3.2 only

[arr2036]

@levide could you check this change works?

[levide]

@arr2036 sorry, I forgot to say that this is in master branch

attr value in urlencode: 0xf44007d40000000395169ad1
attr value in json: �@\u0007�\u0000\u0000\u0000\u0003�\u0016��

[arr2036]

In that case you want to raise your bug report against json-c, and request they escape chars > 0x7E, or better, implement UTF8 char detection:

freeradius-server/src/lib/util/print.c

Line 39 in 45f465b

inline size_t fr_utf8_char(uint8_t const *str, ssize_t inlen)

https://github.com/json-c/json-c/blob/dabed80523fa5101e30f0ee57ba06b02beae73eb/json_object.c#L233