Control sub-TLV attributes order in rest module
Hi, I'm using the freeradius rest module to convert form json to radius format. I have a TLV attribute with several sub-attributes and I want to control the order that the rest module puts the sub attributes. For example, lets say I have an example TLV (tlv_example) with 2 sub attributes, a string (*sub1*) and an integer (*sub2*). I want to create 2 instances of the *tlv_example*, each with its own 2 sub attributes. How should I send the information to the rest module in a way that it would generate 2 seperate AVPs (one for each tlv) and how can I control the order of the sub-attributes inside each AVP? The format I used so far was sending an array for each sub attribute and this created a single AVP that contained all of the sub attributes in the follwoing order: <sub1_instance1><sub1_instance2><sub2_instance1><sub2_instance2> Meaning all instances of the same sub attribute were grouped together and i would like the format to be: <sub1_instance1<sub2_instance1>><sub1_instance2><sub2_instance2> Meaning all sub attributes of the same instance to be grouped (in a seperate TLV). What is the json format I need to use for that to happen? Thanks, Avner
On Sep 10, 2017, at 4:21 AM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
I want to create 2 instances of the *tlv_example*, each with its own 2 sub attributes. How should I send the information to the rest module in a way that it would generate 2 seperate AVPs (one for each tlv) and how can I control the order of the sub-attributes inside each AVP?
You format the json the same way you want the attributes formatted: parent1 child1 child2 parent2 child1 child2 Alan DeKok.
The parents have the same name and as far as I can tell, nesting attributes aren't implemented in the rest module. Could you write the json that you think will do the job? On 10 Sep 2017 15:56, "Alan DeKok" <aland@deployingradius.com> wrote: On Sep 10, 2017, at 4:21 AM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
I want to create 2 instances of the *tlv_example*, each with its own 2 sub attributes. How should I send the information to the rest module in a way that it would generate 2 seperate AVPs (one for each tlv) and how can I control the order of the sub-attributes inside each AVP?
You format the json the same way you want the attributes formatted:
parent1
child1 child2 parent2 child1 child2
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Sep 10, 2017, at 9:26 AM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
The parents have the same name and as far as I can tell, nesting attributes aren't implemented in the rest module.
Hmm... I think it was added in v4. In v3, you should be able to just put the attributes in sequence. The server will take care of encoding them correctly: child1a child2a child1b child2b Alan DeKok.
But how can he handle several attributes with the same name in the json? Doesn't it get converted to a map and then only the last instance gets encoded? On 10 Sep 2017 16:54, "Alan DeKok" <aland@deployingradius.com> wrote: On Sep 10, 2017, at 9:26 AM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
The parents have the same name and as far as I can tell, nesting
attributes
aren't implemented in the rest module.
Hmm... I think it was added in v4.
In v3, you should be able to just put the attributes in sequence. The server will take care of encoding them correctly:
child1a child2a child1b child2b
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Sep 10, 2017, at 1:33 PM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
But how can he handle several attributes with the same name in the json?
Did you try it? Or are you just arguing for the theoretical knowledge of how it works?
Doesn't it get converted to a map and then only the last instance gets encoded?
What does the documentation say how the module works? And does the rest module documentation describe how the json should be encoded? And does the rest module documentation describe what it does with the json data? I mean... come on. You can ask endless questions, or you can (a) try it and see what happens, and (b) read the documentation. This shouldn't be complicated. Learn how to read documentation, and learn how to run tests. Alan DeKok.
The documentation is quite lacking for the rest module, and contains features not yet published in version 3 (such as sub attributes). I did try many different options but none of them seemed to do the trick. When sending several instances of the same sub attribute in the json message only the last one was parsed by the rest module. Sending each sub attribute as a list of values works for parsing them all, but puts them one after the other in the radius packet and this is not what I need. I just want a way to send the same attribute several times and be able to control their order in the resulting radius packet. To summarize, I have a tlv with 2 sub attributes (sub1 and sub2). I want to send several instances of sub_1 and several instances of sub_2 in a json message to the rest module such that the resulting radius packet generated from the rest module will contain each instance of sub_attr_2 after its matching instance of sub_attr_1. I would appreciate a concrete json example :-) On Sun, Sep 10, 2017 at 9:58 PM Alan DeKok <aland@deployingradius.com> wrote:
On Sep 10, 2017, at 1:33 PM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
What does the documentation say how the module works?
And does the rest module documentation describe how the json should be encoded?
And does the rest module documentation describe what it does with the json data?
I mean... come on. You can ask endless questions, or you can (a) try it and see what happens, and (b) read the documentation.
This shouldn't be complicated. Learn how to read documentation, and learn how to run tests.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 11, 2017, at 7:02 AM, Avner Elizarov <avnerelizarov@gmail.com> wrote:
The documentation is quite lacking for the rest module, and contains features not yet published in version 3 (such as sub attributes).
Well, no. V3 supports sub attributes. You just list them sequentially. As I suggested. If you run the server in debug mode and send it multiple sub-attributes, you'll see them in the debug output... sequentially.
I did try many different options but none of them seemed to do the trick.
See the FAQ for "it doesn't work".
When sending several instances of the same sub attribute in the json message only the last one was parsed by the rest module.
The code parses all of them. If you use the correct operator, it uses the operator to determine whether to add them, over-write earlier ones, etc. This is documented...
Sending each sub attribute as a list of values works for parsing them all, but puts them one after the other in the radius packet and this is not what I need.
Which is why I didn't suggest doing that.
I just want a way to send the same attribute several times and be able to control their order in the resulting radius packet.
You do what I suggested.
To summarize, I have a tlv with 2 sub attributes (sub1 and sub2). I want to send several instances of sub_1 and several instances of sub_2 in a json message to the rest module such that the resulting radius packet generated from the rest module will contain each instance of sub_attr_2 after its matching instance of sub_attr_1.
Which is what you've been saying... over and over. That much is clear. There's no need to repeat it again.
I would appreciate a concrete json example :-)
The documentation describes what format to use. You've clearly got far enough to actually create json which mostly works, but... - you don't actually say what you did - you don't post debug outputs This is an open source project, where people answer questions here for free. I'm happy to fix bugs in the server, because that's my responsibility. It's your responsibility to follow the documentation. Both for how to create json, and also for what to do when things go wrong. Alan DeKok.
On 11 Sep 2017, at 18:02, Avner Elizarov <avnerelizarov@gmail.com> wrote:
The documentation is quite lacking
That's simply not true. Every config item is documented other than the TLS ones, which are identical to every other instance to a module acting as a TLS client. There are big blocks of text with example output and expected responses from the HTTP server (for JSON). There are tables showing how HTTP codes map to internal rcodes.
for the rest module, and contains features not yet published in version 3 (such as sub attributes).
Where‽ I don't see anything that describes sub-attributes. In v3.0.x and v4.0.x attributes do not have a nested structure. TLVs are purely for numberspacing, with all attributes sharing a single namespace. If you encode a leaf attribute using the JSON encoder, the JSON won't be structured any differently, you'll just get the name of the attribute. This may change in two ways in v4.0.x. 1) We're planning on fragmenting the namespace and numberspace of attributes into protocol specific dictionaries. 2) We may add support for structural attributes that can contain other attributes.
I did try many different options but none of them seemed to do the trick.
Post examples of what you tried and debug output.
When sending several instances of the same sub attribute in the json message only the last one was parsed by the rest module.
Use the '+=' operator, the documentation clearly says the operator defaults to ':='. Fine... fine that bit isn't super clear. I'll edit the docs to add a note for that.
Sending each sub attribute as a list of values works for parsing them all, but puts them one after the other in the radius packet and this is not what I need. I just want a way to send the same attribute several times and be able to control their order in the resulting radius packet. To summarize, I have a tlv with 2 sub attributes (sub1 and sub2). I want to send several instances of sub_1 and several instances of sub_2 in a json message to the rest module such that the resulting radius packet generated from the rest module will contain each instance of sub_attr_2 after its matching instance of sub_attr_1.
I would appreciate a concrete json example :-)
It's not supported. -Arran
On Sep 11, 2017, at 10:44 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 11 Sep 2017, at 18:02, Avner Elizarov <avnerelizarov@gmail.com> wrote:
The documentation is quite lacking
That's simply not true.
In this case, the usual pattern has been followed: Q: I'm trying to do stuff.. what do I do? A: here's some general guidelines Q: it doesn't work, I tried to do more stuff, it doesn't work! A: here's some more help Q: I tried more stuff, and it still doesn't work! A: perhaps you could say WHAT you were doing, and WHAT happened? Q: you guys suck! Your documentation sucks! Uh... no. It was pretty clear from the second email that the guy was not reading the docs, and paying little attention to how the system works, and not really trying any tests to see what the server does. Just "You guys suck!"
for the rest module, and contains features not yet published in version 3 (such as sub attributes).
Where‽ I don't see anything that describes sub-attributes.
He wants to use sub attributes, and thinks they're magic. Instead of reading the docs and examples, or *trying* different packets, he's upset because the documentation doesn't match his misconception of how the server works. *Nothing* in the documentation talks about sub-attributes. Therefore his conclusion is that v3 doesn't support them, despite thousands of ATTRIBUTE entries in the dictionaries which are, in fact, sub-attributes. To fix that misconception, all he had to do was a simple test of sending / receiving sub-attributes... via something *other* than the rest module. But he wanted to use the REST module... so why would he do tests with other parts of the server to see how it works?
Post examples of what you tried and debug output.
I suspect that won't happen.
When sending several instances of the same sub attribute in the json message only the last one was parsed by the rest module.
Use the '+=' operator, the documentation clearly says the operator defaults to ':='. Fine... fine that bit isn't super clear. I'll edit the docs to add a note for that.
The use of "operator" is clear, and is documented extensively all through the rest of the server. Alan DeKok.
From the examples OP is assuming TLVs are structural so I think that's throwing off their assumptions generally. OP - Again - RADIUS TLVs are not structural, they're used purely to extend the numberspace, the only reason why they're packed inside one another is for efficiency, not to indicate a parent/child relationship between the attributes.
The use of "operator" is clear, and is documented extensively all through the rest of the server.
Yes, just not sure the behaviour is quite what people expect... But OTOH it is the correct behaviour given how the server works elsewhere. -Arran
Thanks everyone for trying to help :-) I've tried many different options in the json and none of them did what I wanted. When my json looked like this: {"attr": {"op": "+=", "value":"value1"}, "attr": {"op": "+=", "value":"value2"}} only the second instance of "attr" was parsed by the rest module (The debug log only printed the last value - "value2" and there was no mention of "value1") and the response contained only the last value. The only way I got the rest module to parse several instances of the same attribute is by using an array like this: {"attr": ["value1", "value2"]} however this results in all the values being adjacent on the resulting packet created and I want to seperate them. Am I missing something regarding the use of the "+=" operator? It seems that because of the dict-like structure of json it isn't possible to have more than one attribute with the same name in the json. On Wed, Sep 13, 2017 at 4:32 AM Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
From the examples OP is assuming TLVs are structural so I think that's throwing off their assumptions generally.
OP - Again - RADIUS TLVs are not structural, they're used purely to extend the numberspace, the only reason why they're packed inside one another is for efficiency, not to indicate a parent/child relationship between the attributes.
The use of "operator" is clear, and is documented extensively all through the rest of the server.
Yes, just not sure the behaviour is quite what people expect... But OTOH it is the correct behaviour given how the server works elsewhere.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
2017-09-10 20:33 GMT+03:00 Avner Elizarov <avnerelizarov@gmail.com>:
But how can he handle several attributes with the same name in the json?
Not sure if I understood your issue But, to answer that question: To add multiple attributes of the same name in JSON: { "Reply-Message":{ op:"+=", value:{ "This value will be stored in the first Reply-Message attribute", "This value will be stored in another Reply-Message attribute" } } } The reply list default list for the attributes in the JSON reply so I think the following might also work: Add two Reply-Message attributes: { "Reply-Message": "This value will be stored in the first Reply-Message attribute", "reply:Reply-Message":{ op:"+=", value:{ "This is another Reply-Message attribute" } } }
On Sun, Sep 10, 2017 at 10:53 PM, Бенджамин Томпсон <b.thompson@latera.ru> wrote:
2017-09-10 20:33 GMT+03:00 Avner Elizarov <avnerelizarov@gmail.com>:
But how can he handle several attributes with the same name in the json?
Not sure if I understood your issue
But, to answer that question:
To add multiple attributes of the same name in JSON:
{ "Reply-Message":{ op:"+=", value:{ "This value will be stored in the first Reply-Message attribute", "This value will be stored in another Reply-Message attribute" } } } Thank you very much for the examples. I need to separate the different attributes because I want to put other attributes in between. This forces them to be adjacent.
The reply list default list for the attributes in the JSON reply so I think the following might also work:
Add two Reply-Message attributes:
{ "Reply-Message": "This value will be stored in the first Reply-Message attribute", "reply:Reply-Message":{ op:"+=", value:{ "This is another Reply-Message attribute" } } } This is better since I can separate the attributes, however I need more than 2 attributes with the same name. List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Avner Elizarov -
Бенджамин Томпсон