On 31 Oct 2013, at 12:20, Alex Hermann alex@speakup.nl wrote:
On Thursday 31 October 2013, Charles Chance wrote:
On 31 Oct 2013 08:53, "Alex Hermann" alex@speakup.nl wrote:
If not, then, imho, the admin already has plenty of possibilities
(IP-based,
digest, TLS cert) to do authentication before calling that function. Why force one method if we can just leave it up to the admin to choose whatever fits best in his situation.
But aren't we allowing the admin to potentially shoot themselves in the foot, as Olle puts it?
Of course, but there are plenty ways to shoot oneself. Kamailio is not an end- user application. I see it more like a compiler than a word-processor. Certain capabilities are required to make an application with it.
Agree that it's not an end-user application. But as we see in Asterisk the admin is changing away from the Unix and TCP/IP network specialist. I have students in Kamailio classes that doesn't understand how to edit config files. That did not happen three years ago. They all knew more about LInux than me then.
This should affect how we package and deliver our product.
I prefer the freedom to choose whatever method fits best in my situation/application. I like the current way in which the admin decides how INVITE, PUBLISH, XMLRPC, DMQ, etc are authenticated and/or authorized. None of the (C-)code handling those methods need special authentication routines implemented, it can all be done from within the script.
I never wanted to stop freedom to choose. But I no longer wanted the default to be "oh, and if you want to secure it go ahead and do it yourself". We need to start thinking security by default.
Implementing additional authorization methods inside DMQ will limit choice and create a higher burden on maintenance of the module.
I don't think so as long as we don't disable all the rest.
/O