sending multiple Class attributes in Rest POST

Mark Grayson (mgrayson) mgrayson at cisco.com
Thu Oct 1 10:10:50 CEST 2020


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 at deployingradius.com> wrote:

    On Sep 30, 2020, at 8:47 AM, Mark Grayson (mgrayson) <mgrayson at 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.





More information about the Freeradius-Users mailing list