couchbase accounting/authentication module
The couchbase accounting/authentication module that I have been working has gotten to a stable point and is currently being used in our production environment thanks to all the help I received on this list over the past several months. Recent discussions about other modules being included in subsequent releases made me think this may benefit others besides myself. The code is available on GitHub: https://github.com/leprechau/rlm_couchbase I’d welcome any comments. It’s using the same json-c library as the rest module to parse documents fetched from couchbase. — Aaron
On 30 Apr 2014, at 17:34, Aaron Hurt <ahurt@ena.com> wrote:
The couchbase accounting/authentication module that I have been working has gotten to a stable point and is currently being used in our production environment thanks to all the help I received on this list over the past several months. Recent discussions about other modules being included in subsequent releases made me think this may benefit others besides myself. The code is available on GitHub:
https://github.com/leprechau/rlm_couchbase
I’d welcome any comments. It’s using the same json-c library as the rest module to parse documents fetched from couchbase.
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. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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. 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. — Aaron
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
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
participants (2)
-
Aaron Hurt -
Arran Cudbard-Bell