[sr-dev] auth apis & radius (was: [SR-Users] auth_radius - Segmentation fault)

[Andrei Pelinescu-Onciul]

On Jun 14, 2010 at 13:00, Juha Heinanen <jh at tutpro.com> wrote:
> Andrei Pelinescu-Onciul writes:
> 
> > We need either to quickly merge the auth apis or revive
> > modules_s/auth_radius (and probably the other modules_s/*radius).
> > Unfortunately merging the auth api doesn't look like a quick job:
> > ser auth api:
> >  + build_challenge()
> >  + qop
> >  + calc_response()
> > k auth api:
> >  + rpid_avp
> >  + rpid_avp_type
> >  + check_response()
> > 
> > so reviving the modules_s/*radius looks like the quick fix (at least
> > for 3.0).
> > So anybody against reviving them in 3.0? (or does anybody remember any
> > problem with the s versions?)
> 
> fine with me.  what modules would you then suggest to use for radius
> authorization?

I'm plannig to revert:

commit 456c3c137e9abcf687413f9675fe0f1761ce820d
Author: Juha Heinanen <jh at tutpro.com>
Date:   Mon Apr 20 08:47:28 2009 +0300

    * Modules: auth_radius, misc_radius
    
    Moved modules_k/auth_radius and modules_k/misc_radius to modules and
    removed modules_s/auth_radius, modules_s/avp_radius, and modules_s/uri_radiu

This means that when using modules_s/auth, one would have to use
 modules_s/auth_radius and for modules_k/auth  => modules_k/auth_radius.

We can re-revert the commit once we have the auth apis merged.

Another change that I'm considering is renaming bind_auth, bind_auth_t &
auth_api to *_s and *_k , so that in the future we'll get an error in
this cases (it won't be possible for one module to use the wrong auth
api). This would also allow loading both auth modules in the same time.


Andrei