Feature requests and current limitations in
As discussed at https://github.com/FreeRADIUS/freeradius-server/issues/1451#issuecomment-164..., I'm currently trying to write a proposal to change the interface of the programming language that are currently supported as embedded languages within FreeRADIUS. The current list includes Perl, Python and Ruby (which should not be used). In the current status rlm_perl is far superior in terms of features to the other modules, and also has a completely different interface. My plan is to make a unified interface for these three modules, so they all have the same features and behave in the same way. At the moment, the biggest limitations that should be removed are the following: - Make the modules work in the same way, so an example in a language can simply be rewritten to another language (rlm_perl is currently the most mature and works completely different from rlm_python and rlm_ruby) - Don't limit the input of rlm_python and rlm_ruby to the request list, include other lists (like reply and session-state) as well - Don't limit the output of rlm_python and rlm_ruby to the reply and control list, include others lists (like session-state) as well Some lesser changes will include: - Allow random config structures to be passed to the module, as rlm_perl now has the "config" option <https://github.com/FreeRADIUS/freeradius-server/issues/1451> - Rewrite rlm_ruby to use mruby <https://github.com/FreeRADIUS/freeradius-server/issues/990> - Fix multithreading in rlm_python <https://github.com/FreeRADIUS/freeradius-server/issues/408> - Strip the extra quotes in rlm_python <https://github.com/FreeRADIUS/freeradius-server/issues/1452> - Lots of minor fixes (e.g. <https://github.com/FreeRADIUS/freeradius-server/pull/1459>) I don't know if anyone here uses one of these modules, or tried using one but stopped due to its limitations, but I'm really curious what kind of features people would want to see in these modules, or what limitations they'd experienced with using them. Disclaimer: I'll write the proposal for change, will discuss it on the mailing lists, and I'll try to implement it too. I have very limited experience in writing this kind of code, which means it may be a learnful but slow progress. Also, keep in mind that I'm not related to the FreeRADIUS project, other than just contributing a pull request every now and then: I'm not in a position to decide what comes into the code base and what not. -- Herwin Weststrate
On 19/12/15 10:45, Herwin Weststrate wrote:
My plan is to make a unified interface for these three modules, so they all have the same features and behave in the same way. At the moment, the biggest limitations that should be removed are the following:
These all sound like excellent ideas; well done for taking it on.
I don't know if anyone here uses one of these modules, or tried using one but stopped due to its limitations, but I'm really curious what kind of features people would want to see in these modules, or what limitations they'd experienced with using them.
It might be interesting for the modules to be able to call back into some of the more relevant server core functions. An example might be registering dict attribute, attribute comparison functions and xlats, which then call back into the scripting language, e.g.: # rlm_python example def instantiate(config): attr = config.server.dict_register('Dyn-Attr', 'integer') attr.compare_func = my_compare config.server.xlat_register('dynaxlat', myxlatfunc) ...but I suspect that would be a *lot* of work. I'm kind of interested in an rlm_javascript and rlm_lua which might be more accessible to people.
On Dec 21, 2015, at 5:53 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
It might be interesting for the modules to be able to call back into some of the more relevant server core functions.
That's good, but very hard. The core has tons of APIs which *might* be called from a language.
I'm kind of interested in an rlm_javascript and rlm_lua which might be more accessible to people.
Sure. There are a few small Javascript implements. http://duktape.org/ is one which seems useful, and simple to integrate. A rlm_javascript module using duktape would probably be pretty small. Alan DeKok.
On Dec 19, 2015, at 5:45 AM, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
My plan is to make a unified interface for these three modules, so they all have the same features and behave in the same way. At the moment, the biggest limitations that should be removed are the following:
Each language has it's own API, which makes it difficult to have common code on FreeRADIUS.
- Make the modules work in the same way, so an example in a language can simply be rewritten to another language (rlm_perl is currently the most mature and works completely different from rlm_python and rlm_ruby) - Don't limit the input of rlm_python and rlm_ruby to the request list, include other lists (like reply and session-state) as well - Don't limit the output of rlm_python and rlm_ruby to the reply and control list, include others lists (like session-state) as well
Those are all good ideas.
Some lesser changes will include:
- Allow random config structures to be passed to the module, as rlm_perl now has the "config" option <https://github.com/FreeRADIUS/freeradius-server/issues/1451> - Rewrite rlm_ruby to use mruby <https://github.com/FreeRADIUS/freeradius-server/issues/990> - Fix multithreading in rlm_python <https://github.com/FreeRADIUS/freeradius-server/issues/408> - Strip the extra quotes in rlm_python <https://github.com/FreeRADIUS/freeradius-server/issues/1452> - Lots of minor fixes (e.g. <https://github.com/FreeRADIUS/freeradius-server/pull/1459>)
That's ambitious, but all good.
Disclaimer: I'll write the proposal for change, will discuss it on the mailing lists, and I'll try to implement it too. I have very limited experience in writing this kind of code, which means it may be a learnful but slow progress. Also, keep in mind that I'm not related to the FreeRADIUS project, other than just contributing a pull request every now and then: I'm not in a position to decide what comes into the code base and what not.
Sure. Pull requests will get reviewed, and often merged. Alan DeKok.
participants (3)
-
Alan DeKok -
Herwin Weststrate -
Phil Mayers