On Tue, Nov 08, 2011 at 05:18:59PM +0100, Arran Cudbard-Bell wrote:
Regarding unlang, the format proposed is actually *more* flexible than the current unlang 'update' constructs :)
I would hope that changes in future - and if I had enough time I would try to implement it myself (the main issue being getting my head around the two distinct sets of operator code) I think there could be a feature that every attribute could also identify the list, with a default list based on the context for tidiness and backwards compatibility. Example 'users' file: steve control:Huntgroup-Name =~ "foo", reply:Framed-IP-Address =~ "." request:Huntgroup-Name := "bar" reply:Framed-Protocol := PPP Here we would default to request: or control: in the first line, dependent on the operator; and default to reply: for the remaining lines. In rlm_mysql: attributes returned can have a list prefix, but similarly default to request:/control: in authorize_check_query, and to reply: in authorize_reply_query In unlang: if (control:Huntgroup-Name =~ /foo/ && reply:Framed-IP-Address =~ /./) { update { request:Huntgroup-Name := "bar" reply:Service-Type = PPP } } Some of my configs would be hugely simplified if I did this. At the moment I have to copy attributes from the Reply list to the Request list, just so that rlm_sql can test on their presence.
Running the values through XLAT also exposes all kinds of additional awesomeness.
And dangers :-) But allowing that is part of the semantics of rlm_rest I think, rather than the JSON format itself. rlm_rest could have a flag to enable or disable this. Personally I don't like expansions to have side-effects. If the debug level were instead controlled by an attribute on the control: list, then you could just return a regular update. Regards, Brian.