On Apr 30, 2014, at 12:15 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
Right, sorry about the misunderstanding. I’ll submit a pull request today.
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.
I fixed this and it’s now just using the key/value pairs from the ‘map’ section of the config to map attributes. — Aaron