31 Oct
2013
31 Oct
'13
8:53 a.m.
On 31 Oct 2013, at 12:20, Alex Hermann <alex(a)speakup.nl> wrote:
On Thursday 31 October 2013, Charles Chance wrote:
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.
On 31 Oct 2013 08:53, "Alex Hermann"
<alex(a)speakup.nl> wrote:
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. 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?
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