[sr-dev] [SR-Users] auth apis & radius

Andrei Pelinescu-Onciul andrei at iptel.org
Mon Jun 14 16:03:20 CEST 2010


On Jun 14, 2010 at 15:35, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
> >On Jun 14, 2010 at 15:19, Henning Westerholt<henning.westerholt at 1und1.de>  wrote:
> >>On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
> >>>>Indeed the ser auth module is superiour in this areas to the kamailio
> >>>>one. I can't judge about the auth_radius side, as i did not used it so
> >>>>far.
> >>>I have no idea about the radius part either (Juha knows better). The
> >>>problem is that right now if one wants to use auth from module_s and
> >>>radius, he/she can't and the quickest way to fix it is to temporarily
> >>>revive the modules_s/*radius stuff (which will have the unpleasant
> >>>side-effect of some path changes: modules/auth_radius =>
> >>>modules_k/auth_radius and modules/misc_radius =>  modules_k/misc_radius).
> >>Hi Andrei,
> >>
> >>so if i understand correctly the main problem is the name space colision in
> >>the auth api? What about renaming the auth API binding function, as you
> >>suggested in another mail and extending the docs a bit? Then at least it
> >>should work with auth from k, and we don't need to change the paths for this
> >>modules.
> >There is still the problem of specifying the path in  the cfg.
> >If one has loadpath "modules:modules_s", and laodmodule "auth_radius"
> >  =>  modules/auth_radius is loaded =>  problems.
> >OTOH if modules/auth_radius is moved back to modules_k/auth_radius
> >  =>  no problem for default cfgs for both ser and kamailio.
> reverting on K 3.0 branch will break packaging now. modules_s are
> not packaged by k 3.0 and I would prefer not to break much stable
> version.

Since K3.0 doesn't package modules_s, it doesn't have to pick up the
change. I was sepaking of sr_3.0.
> 
> For 3.1 I would go for merging the auth modules. K version has some
> functions for using PVs to get username and password, which is handy
> for LDAP auth with K ldap module.

Sure, but until then we better revert it (I don't have time to
merge the apis right now).

Andrei



More information about the sr-dev mailing list