Standardised JSON VP list format

[Arran Cudbard-Bell]

On 10 Nov 2011, at 17:49, Phil Mayers wrote:

> On 10/11/11 16:23, Arran Cudbard-Bell wrote:
>> 
>> On 10 Nov 2011, at 16:48, Phil Mayers wrote:
>> 
>>> On 10/11/11 14:54, Arran Cudbard-Bell wrote:
>>> 
>>>> If users want to admins want to expose more than the request list they can copy the values
>>>> across...
>>> 
>>> Ugh. So rlm_sql all over again... please no!
>> 
>> *if admins want to
>> 
>> So you want to do what? Include the entire control list with the password hashes?
> 
> A common use case for similar modules is to EXTRACT the password hash from some database, and give it to FreeRADIUS. So there's a good chance a lot of password hashes will be flying around in the returned JSON.
> 
> If they're doing PAP, the User-Password field will be in the JSON. And so on.
> 
> So unless you're going to provide an attribute filtering mechanism (good luck supporting that on the mailing list!) you're going to have to face attribute privacy issues anyway. Does rlm_rest support HTTPS?
> 

Yes, I was planning to use attrfilter. Yes it will support HTTPS.

And I disagree with most of what you said above...

This is not like rlm_sql which calls a relatively simple dumb backend database. This module is meant to bridge FreeRADIUS with a webservice, a webservice is as smart or dumb as its author makes it.

> Anyway, no - that's not what I want. What I *don't* want is to have to do this:

Why do you want to include reply items in the request body?

Why do you want to include control items in the request body?


> update request {
>   Var = "%{reply:Var}"
>   Var2 = "%{control:Var2}"
> }
> 
> How about a module config item:
> 
> modules {
>  rest myserver {
>    # which attributes do we send to the server
>    request_pairs = yes
>    control_pairs = no
>    reply_pairs = no
>  }
> }

No.

-Arran

Arran Cudbard-Bell
a.cudbardb at networkradius.com

Technical consultant and solutions architect

15 Ave. du Granier, Meylan, France
+33 4 69 66 54 50