On 11 Nov 2011, at 00:13, Brian Candler wrote:
On Thu, Nov 10, 2011 at 09:59:02PM +0100, Arran Cudbard-Bell wrote:
Why do you want to include reply items in the request body?
I can give you a concrete usage case for this.
You've built up a partial reply so far, by looking up attributes for a user in some database. Now you want to supplement that with a policy decision, implemented by rlm_rest.
The policy says: if this user has a static IP address, then tunnel them to a farm of static LNSes (unless the request was from one of those LNSes).
Hmm fair enough. Well i've been discussing some changes with Alan that would allow VALUE_PAIR to carry a 'source/target' list. I.e. you can create a temporary list of VPs, and then pass that to pairmove with a request, which'll sort them into the correct list. But you could also write the source list in there, and then include that as either an encapsulating JSON object "request":{} or just as part of the attribute name "request:<attr>". Then attrfilter needs to be modified to take calls from other modules, and the attributes you want to include from other lists go in there. reply:<name> *= ANY User-Name *= ANY Tmp-String-0 := "My extra special web API attribute that you only see here"
Why do you want to include control items in the request body?
That one I don't have a case for, but the control list is sometimes a convenient dumping ground for temporary variables. These could go in the request list instead.
They can also go in header data which is what I was hinting at before. For rlm_rest this would be something like: uri = "http://example.org/user/%{User-Name}?auth-type=%{control:Auth-Type}"
But I also think there is value in making the input and output JSON formats identical. If the reply can set attributes in control and reply lists, then I think it's reasonable that the request should be able to carry those lists too.
Yes. -Arran Arran Cudbard-Bell a.cudbardb@networkradius.com Technical consultant and solutions architect 15 Ave. du Granier, Meylan, France +33 4 69 66 54 50