Thanks Alan! I can now see those being POSTed using the accounting section showing attributes being returned by the NAS, but I can't seem to see them in the post-auth section being returned in the access-accept. post-auth {                 uri = "${..connect_uri}/rest/radius"                 method = 'post'                 body = 'json'                 data = '{"class1":"%{Class[0]}","class2":"%{Class[1]"}'                 tls = ${..tls}         } What am I doing wrong to enable POSTing of access-accept attributes? Cheers, Mark On 29/09/2020, 13:17, "Alan DeKok" <aland@deployingradius.com> wrote: On Sep 29, 2020, at 8:08 AM, Mark Grayson (mgrayson) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote: > Is there a way to be able to POST multiple Class attributes using Rest? > > I am currently testing returning multiple class attributes and can see they are being sent in the accounting-request trace: > > > (10) Framed-IP-Address = 10.192.230.1 > > (10) Class = 0x31323334353637383957424149443d64756d6d792e6d656d6265723a5553 > > (10) Class = 0x37334a773b51793453716c44264e5548405929 > > Is there a way I can pass both received class attributes in a rest POST? > > It looks like the Rest %{Class} simply picks the first one. Yes. $ man unlang %{Class[0]} picks the first one %{Class[1]} picked the second one etc. Alan DeKok.

Thanks Alan! However, I am still not getting the reply attribute passed. Here is the debug showing expansion happily picks up username but not any of the reply attributes. Is it due to the ordering of update replay after rlm_rest? Any pointers gratefully received. Cheers, Mark (8) eap: Sending EAP Success (code 3) ID 237 length 4 (8) eap: Freeing handler (8)     [eap] = ok (8)   } # authenticate = ok (8) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default (8)   post-auth { (8)     update control { (8)       &REST-HTTP-Header := "x-api-key: <<removed>>" (8)     } # update control = noop rlm_rest (rest): Reserved connection (0) (8) rest: Expanding URI components (8) rest: EXPAND https://<<removed>> (8) rest:    --> https://<<removed>> (8) rest: EXPAND /rest/radius (8) rest:    --> /rest/radius (8) rest: Sending HTTP POST to "https://<<removed>>" (8) rest: EXPAND {"class1":"%{reply:Class[0]}","class2":"%{reply:Class[1]}","idleTimeout":"%{reply:Idle-Timeout}","sessionTimeout":"%{reply:Session-Timeout}","interimAcctInterval":"%{reply:Acct-Interim-Interval}","userName":"%{User-Name}"} (8) rest:    --> {"class1":"","class2":"","idleTimeout":"","sessionTimeout":"","interimAcctInterval":"","userName":"bob"} (8) rest: Processing response header (8) rest:   Status : 201 (Created) (8) rest:   Type   : json (application/json) (8) rest: Parsing attribute "_id" (8) rest: WARNING: Failed parsing attribute: Invalid vendor name in attribute name "_id", skipping... rlm_rest (rest): Released connection (0) Need 5 more connections to reach 10 spares rlm_rest (rest): Opening additional connection (5), 1 of 27 pending slots used rlm_rest (rest): Connecting to "<<removed>>" (8)     [rest] = ok (8)     update reply { (8)       Class = 0x31323334353637383957424149443d64756d6d792e6d656d6265723a5553 (8)       Class += 0x37334a773b51793453716c44264e5548405929 (8)       Acct-Interim-Interval := 60 (8)       Session-Timeout := 300 (8)     } # update reply = noop On 30/09/2020, 13:54, "Alan DeKok" <aland@deployingradius.com> wrote: On Sep 30, 2020, at 8:47 AM, Mark Grayson (mgrayson) <mgrayson@cisco.com> wrote: > > I can now see those being POSTed using the accounting section showing attributes being returned by the NAS, but I can't seem to see them in the post-auth section being returned in the access-accept. > > post-auth { > uri = "${..connect_uri}/rest/radius" > method = 'post' > body = 'json' > data = '{"class1":"%{Class[0]}","class2":"%{Class[1]"}' That is taking the Class values from the *request*. > tls = ${..tls} > } > > What am I doing wrong to enable POSTing of access-accept attributes? $ man unlang You can use reply:Class to reference attributes in the reply. Alan DeKok.

On Oct 1, 2020, at 3:10 AM, Mark Grayson (mgrayson) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Thanks Alan!

However, I am still not getting the reply attribute passed. Here is the debug showing expansion happily picks up username but not any of the reply attributes. Is it due to the ordering of update replay after rlm_rest?

Add another -x to see the response received by the rest module. I suspect the response is in an invalid format given the warning. -Arran