On 30 Apr 2014, at 18:05, Aaron Hurt <ahurt@ena.com> wrote:
On Apr 30, 2014, at 11:50 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Interesting. It's the sort of thing that could be merged into rlm_rest at some point as a sub-module.
But for now I don't see any issues in including it in v3.x.x. I do have a few comments, but they're easier made on a pull request.
I think the map section would have to change, it wouldn't be overly difficult to represent it as a set of config pairs, and you could even do nesting if you wanted a more complex structure.
Thank you, looking forward to the pull request.
If you want your module included in v3.x.x branch please send a pull request against v3.x.x.
I do agree the ‘map’ part is a bit ugly but I wasn’t sure how to structure a config parser for an unknown set of keys.
The FreeRADIUS config parser is just a key value store, you don't need to know the structure before hand. See the 'update {}' section in rlm_ldap. You can just do: map { <couch db attr> = <radius attr> } Or which ever way round you want it. You might want to consider using a similar system as rlm_sql does for accounting queries to dynamically decide which mapping section will be used, based on the type of NAS sending the Accounting-Request. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2