[rlm_rest] do not translate attribute values

[Michael Schneider]

Hi Matthew

> On 18 Dec 2020, at 00:03, Matthew Newton <mcn at freeradius.org> wrote:
> 
> On 17/12/2020 20:47, Alan DeKok wrote:
>> On Dec 17, 2020, at 3:11 PM, Michael Schneider <michael.schneider at onway.ch> wrote:
>>> I am using FreeRADIUS version 3.0.21. The server works as expected, but the generated REST request is weird in my opinion. The two attributes "Tunnel-Type (64)" and "Tunnel-Medium-Type (65)" are particularly special. The value type of them is an integer and this is also signaled via REST, but the value provided is the string representation of the integer.
>>   I've pushed a fix for v3.0.x.  It always prints the integer value, and does not print the name.
> 
> In v4 this is configurable (in the code at least, possibly not yet in rlm_rest). But the thing is the "type" is the RADIUS attribute type, whereas the value contains the useful human-readable string value. "type" doesn't mean the JSON type of the following value.
> 
> If it's an integer then it'll be a JSON integer (i.e. not double-quoted). Relying on the value of "type" to know what JSON type it is should be unnecessary; a JSON parser that needs to be told the type is "integer" is broken.

The JSON parser is not the problem. Our REST endpoint is written in Java and we have created classes for all the RADIUS attributes we use. The radius attribute "Tuennel-Type" expects an integer value, but the parser returns a string. So the problem is that the received value type does not match the expected value type. To avoid this problem, we need to go further and understand the value of each attribute and then accept an integer or its string representation.

> The problem at the moment with no config option is that not everyone's going to be happy. Personally I'd think that the original behaviour here was most useful for most people, who wouldn't have an immediate clue what Tunnel-Type 13 is - but "VLAN" makes a lot more sense.
> 
> Hopefully changing it won't break any existing deployments...

I fully agree that "VLAN" is much more readable than 13, but in my opinion rlm_rest is a technical interface and therefore must be technically correct and not human readable. I think a configuration option is needed, otherwise this is a breaking change. If desired, I can try to create an appropriate PR.

- Michael