rest modules JSON replies format and types

Arran Cudbard-Bell a.cudbardb at freeradius.org
Wed Feb 3 22:45:37 CET 2016


> 
> So, does FreeRADIUS actually look at those types in the JSON reply?

No, the types are more to let the REST server know what dictionary types the attributes are.  JSON types are a subset of the datatypes we have in the server.

Reading through the code it looks like the un-martialing function is quite lazy and is just calls json_object_get_string to get a string representation of the type and then fr_pair_value_from_str to convert that to a proper C type.

I suppose if json_object_get_string didn't like being called on integer types it could cause issues.

Try with with compact version:

{
	"Tunnel-Private-Group-ID": 2
}

and then if that doesn't work:

{
	"Tunnel-Private-Group-ID": "2"
}

If the first works, it points to an issues in json_pair_make/leaf, if the second works then it's an issue with json_object_get_string, which would be an easy fix.

Run with -Xx to get extra info.

> Should I be looking into parsing the dictionary files in my REST service to populate the reply with the correct types?
> Not that it would be that hard, but if it does not matter I can find better ways of keeping myself entertained...

Nah.

-Arran

Ignore the bit about recursing.  It'll work some day, just not right now...

/** Processes JSON response and converts it into multiple VALUE_PAIRs
 *
 * Processes JSON attribute declarations in the format below. Will recurse when
 * processing nested attributes. When processing nested attributes flags and
 * operators from previous attributes are not inherited.
 *
 * JSON response format is:
@verbatim
{
	"<attribute0>":{
		"do_xlat":<bool>,
		"is_json":<bool>,
		"op":"<operator>",
		"value":[<value0>,<value1>,<valueN>]
	},
	"<attribute1>":{
		"value":{
			"<nested-attribute0>":{
				"op":"<operator>",
				"value":<value0>
			}
		}
	},
	"<attribute2>":"<value0>",
	"<attributeN>":[<value0>,<value1>,<valueN>]
}
@endverbatim
 *
 * JSON valuepair flags:
 *  - do_xlat	(optional) Controls xlat expansion of values. Defaults to true.
 *  - is_json	(optional) If true, any nested JSON data will be copied to the
 *			   VALUE_PAIR in string form. Defaults to true.
 *  - op	(optional) Controls how the attribute is inserted into
 *			   the target list. Defaults to ':=' (T_OP_SET).
 *
 * If "op" is ':=' or '=', it will be automagically changed to '+=' for the
 * second and subsequent values in multivalued attributes. This does not work
 * between multiple attribute declarations.
 *
 * @see fr_tokens_table
 *
 * @param[in] instance configuration data.
 * @param[in] section configuration data.
 * @param[in] request Current request.
 * @param[in] object containing root node, or parent node.
 * @param[in] level Current nesting level.
 * @param[in] max counter, decremented after each VALUE_PAIR is created,
 * 	      when 0 no more attributes will be processed.
 * @return
 *	- Number of attributes created.
 *	- < 0 on error.
 */
static int json_pair_make(rlm_rest_t const *instance, rlm_rest_section_t *section,
			 REQUEST *request, json_object *object, UNUSED int level, int max)
{

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

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


More information about the Freeradius-Users mailing list