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@networkradius.com Technical consultant and solutions architect 15 Ave. du Granier, Meylan, France +33 4 69 66 54 50