i have now converted k/auth_radius module to use the famed s/auth module. all functionality of existing auth_radius is preserved except for this:
If an empty string "" is used (as realm parameter) then the server will generate it from the request. In case of REGISTER requests To header field domain will be used (because this header field represents a user being registered), for all other messages From header field domain will be used.
so the user needs to always give the realm ($td/$fd/...).
regarding s/auth module, there are differences in parameters as compared to k auth module and www_challenge()/proxy_challenge() have been replaced by digest_challenge avp. this will be shown in README example.
is it ok if i commit the changes or does anyone else care if i'm the only radius user?
-- juha
Hello Juha,
Now that s and k version of the auth_radius are more or less similar, are there any particular reasons against having a single version of auth_radius? In the end, I would like to see a single version for all radius modules.
Regards, Ovidiu Sas
On Fri, Jul 2, 2010 at 3:49 AM, Juha Heinanen jh@tutpro.com wrote:
i have now converted k/auth_radius module to use the famed s/auth module. all functionality of existing auth_radius is preserved except for this:
If an empty string "" is used (as realm parameter) then the server will generate it from the request. In case of REGISTER requests To header field domain will be used (because this header field represents a user being registered), for all other messages From header field domain will be used.
so the user needs to always give the realm ($td/$fd/...).
regarding s/auth module, there are differences in parameters as compared to k auth module and www_challenge()/proxy_challenge() have been replaced by digest_challenge avp. this will be shown in README example.
is it ok if i commit the changes or does anyone else care if i'm the only radius user?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Ovidiu Sas writes:
Now that s and k version of the auth_radius are more or less similar, are there any particular reasons against having a single version of auth_radius?
ovidui,
i compared the two and found that they are too different to make sense to try to merge them: radius attributes differ (big changes in dictionaries), s version includes the to/from attribute code, etc.
In the end, I would like to see a single version for all radius modules.
me too, but it would be a big change to both programmer and user.
-- juha
I see .... In this case, just go ahead and push your changes. If and when you have time, it would be nice to see a wiki page with differences between the two versions. In the future, maybe we will enhance one version with missing functionality from the other one and promote a single common module (by dropping the other one). This will require no merging.
Regards, Ovidiu Sas
On Fri, Jul 2, 2010 at 9:13 AM, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
Now that s and k version of the auth_radius are more or less similar, are there any particular reasons against having a single version of auth_radius?
ovidui,
i compared the two and found that they are too different to make sense to try to merge them: radius attributes differ (big changes in dictionaries), s version includes the to/from attribute code, etc.
In the end, I would like to see a single version for all radius modules.
me too, but it would be a big change to both programmer and user.
-- juha
Ovidiu Sas writes:
I see .... In this case, just go ahead and push your changes. If and when you have time, it would be nice to see a wiki page with differences between the two versions.
i'll mention the differences on the wiki page.
In the future, maybe we will enhance one version with missing functionality from the other one and promote a single common module (by dropping the other one). This will require no merging.
also, it would make sense to have a common auth module that could be based on s one.
-- juha
On Fri, Jul 2, 2010 at 9:29 AM, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
I see .... In this case, just go ahead and push your changes. If and when you have time, it would be nice to see a wiki page with differences between the two versions.
i'll mention the differences on the wiki page.
In the future, maybe we will enhance one version with missing functionality from the other one and promote a single common module (by dropping the other one). This will require no merging.
also, it would make sense to have a common auth module that could be based on s one.
Is this something that can be relatively easy to achieve?
--ovidiu
Ovidiu Sas writes:
also, it would make sense to have a common auth module that could be based on s one.
Is this something that can be relatively easy to achieve?
looks like it, since it didn't take from me more that a hour or so to convert auth_radius module and i would think that it would be similar effort to convert k auth_db and auth_diameter modules.
then these k auth module functions could be dropped:
5.4. is_rpid_user_e164() 5.5. append_rpid_hf() 5.6. append_rpid_hf(prefix, suffix)
and these would need to be migrated from k auth module to s auth module:
5.7. pv_www_authorize(realm) 5.8. pv_proxy_authorize(realm)
-- juha
If it's not a big hurdle, can you take care of it? It would be nice to get rid of as many duplicates modules as we can.
--ovidiu
On Fri, Jul 2, 2010 at 10:46 AM, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
also, it would make sense to have a common auth module that could be based on s one.
Is this something that can be relatively easy to achieve?
looks like it, since it didn't take from me more that a hour or so to convert auth_radius module and i would think that it would be similar effort to convert k auth_db and auth_diameter modules.
then these k auth module functions could be dropped:
5.4. is_rpid_user_e164() 5.5. append_rpid_hf() 5.6. append_rpid_hf(prefix, suffix)
and these would need to be migrated from k auth module to s auth module:
5.7. pv_www_authorize(realm) 5.8. pv_proxy_authorize(realm)
-- juha
Ovidiu Sas writes:
If it's not a big hurdle, can you take care of it? It would be nice to get rid of as many duplicates modules as we can.
i'm afraid to start modifying touch other peoples' modules. if people agree to convert all modules to a single auth module based on s version for sr 3.1 release, i could help in migrating pv_www_authorize(realm) and pv_proxy_authorize(realm) functions. perhaps also www_challenge and proxy_challenge if people think that it is necessary.
-- juha
On Jul 02, 2010 at 10:27, Ovidiu Sas osas@voipembedded.com wrote:
On Fri, Jul 2, 2010 at 9:29 AM, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
I see .... In this case, just go ahead and push your changes. If and when you have time, it would be nice to see a wiki page with differences between the two versions.
i'll mention the differences on the wiki page.
In the future, maybe we will enhance one version with missing functionality from the other one and promote a single common module (by dropping the other one). This will require no merging.
also, it would make sense to have a common auth module that could be based on s one.
Is this something that can be relatively easy to achieve?
My guess is that it would be easy. The differences are mainly in exported callbacks and some missing or extra script functions. k version has the *challenge() functions (which were removed from ser, but could be re-added easily) and some pv stuff. There also 2 or 3 differences in the exported callbacks (which hopefully can be merged easily in such a way that existing ser & k modules could use the merged auth without changes).
Andrei
-
Andrei Pelinescu-Onciul -
Juha Heinanen -
Ovidiu Sas