[Freeswitch-dev] Difference of behaviour between apply-acl profile parameters
Florent Krieg
fkrieg at sewan.eu
Wed Mar 12 19:11:39 MSK 2014
Hello Anthony,
Actually we only use the domains acl (I am not even sure what is 'real
acl', we only use it in correlaton with cidr users' fields),
automatically generated by scanning the user directory (we are in a
multi-homed environment).
Here is an example (taken out from the logs):
switch_utils.c:324 Adding XXX.XXX.XXX.XXX/32 (allow) [account at test]
to list domains
With 'apply-inbound-acl=domains' and 'apply-register-acl=domains', when
XXX.XXX.XXX.XXX tries to register with a random login at domain (eg:
alice at alice, account which doesn't exist at all, assuming we only have
'account at test') to our platform, it goes OK.
If we do a 'sofia_contact alice at alice', it returns the register from the db.
Now:
* if we start a call, it will be authentified as 'account at test' (which
is OK)
* if we receive a call, we won't be able to get the contact for
'account at test' because the record in db is (to_user=)alice and
(reg_host=)alice
So in the last case we have to do static routing. We want to avoid it as
much as possible.
I am not sure whether I am clear...
Regards,
Florent
Le 12/03/2014 15:42, Anthony Minessale a écrit :
> apply-register acl is specifically designed to be used with the
> "domains" acl which is automatically generated by scanning the user
> directory and building a list using the cidr field and tokenizing the
> user to match the range of each acl entry. Its not really useful with
> normal acl's.
>
>
> On Wed, Mar 12, 2014 at 8:23 AM, Florent Krieg <fkrieg at sewan.eu
> <mailto:fkrieg at sewan.eu>> wrote:
>
> I forgot the part of sofia.c that does switch user, please find it
> inlined below.
>
> Le 12/03/2014 14:03, Florent Krieg a écrit :
>> Hello all,
>>
>> While checking and tuning our FreeSWITCH configuration, I found
>> out that there is big difference of behaviour between the
>> apply-inbound-acl and apply-register-acl sofia sip profile
>> parameters.
>> => in the case of 'apply-inbound-acl', requests coming from an IP
>> present in the acl profile list will be authentified as the
>> matching account, which is OK.
>> => in the case of 'apply-register-acl', register requests coming
>> from an IP present in the acl profile list will be authorized
>> (which is OK), while being 'authentified' as the user specified
>> in the SIP request. I would have imagined that register requests
>> would be identified as the matching account as well. We end up in
>> getting crazy registrations (devices registered as user not
>> existing in the directory for instance), when customers' hardware
>> are not permissive enough to allow from (user at domain) field
>> customisation (while outgoing calls are perfectly working).
>>
>> Is that behaviour wanted by the community?
>>
>> I checked the source code which I reckon I am not familiar with
>> at all, and I found that:
>> * apply-inbound-acl (sofia.c):
>>
>> if (profile->acl_count) {
>> uint32_t x = 0;
>> int ok = 1;
>> char *last_acl = NULL;
>> const char *token = NULL;
>>
>> for (x = 0; x < profile->acl_count; x++) {
>> last_acl = profile->acl[x];
>> if ((ok =
>> switch_check_network_list_ip_token(network_ip, last_acl,
>> &token))) {
>>
>> if
>> (profile->acl_pass_context[x]) {
>> acl_context = profile->acl_pass_context[x];
>> }
>>
>> break;
>> }
>>
>> if (profile->acl_fail_context[x]) {
>> acl_context = profile->acl_fail_context[x];
>> } else {
>> acl_context = NULL;
>> }
>> }
>>
>> if (ok) {
>> if (token) {
>> switch_set_string(acl_token, token);
>> }
>> if (sofia_test_pflag(profile,
>> PFLAG_AUTH_CALLS)) {
>> switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "IP
>> %s Approved by acl \"%s[%s]\". Access Granted.\n",
>> network_ip, switch_str_nil(last_acl), acl_token);
>> switch_set_string(sip_acl_authed_by, last_acl);
>> switch_set_string(sip_acl_token, acl_token);
>> is_auth = 1;
>> }
>>
> [...]
>
> if (*acl_token) {
> switch_channel_set_variable(channel, "acl_token", acl_token);
> if (strchr(acl_token, '@')) {
> if (switch_ivr_set_user(session,
> acl_token) == SWITCH_STATUS_SUCCESS) {
> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session),
> SWITCH_LOG_DEBUG, "Authenticating user %s\n", acl_token);
> } else {
> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session),
> SWITCH_LOG_WARNING, "Error Authenticating user %s\n", acl_token);
> }
> }
> }
>
>
>> * apply-register-acl (sofia_reg.c):
>>
>> if (profile->reg_acl_count) {
>> uint32_t x = 0;
>> int ok = 1;
>> char *last_acl = NULL;
>>
>> for (x = 0; x < profile->reg_acl_count; x++) {
>> last_acl = profile->reg_acl[x];
>> if (!(ok =
>> switch_check_network_list_ip(network_ip, last_acl))) {
>> break;
>> }
>> }
>>
>> if (ok && !sofia_test_pflag(profile,
>> PFLAG_BLIND_REG)) {
>> type = REG_AUTO_REGISTER;
>>
>>
>> Is what I expect (similar behaviour in both cases) crazy to you?
>> Or does it sound right?
>>
>> In the latter case, should I open a JIRA case for somebody to
>> push a fix?
>> I could try to 'fix' it myself (in case you consider it as a bug
>> as I do) but I am not really familiar with C development as well.
>>
>> Thank for your points of view!
>> Regards
>> Florent
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>> http://www.freeswitchsolutions.com
>>
>>
>>
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org <mailto:FreeSWITCH-dev at lists.freeswitch.org>
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> <mailto:FreeSWITCH-dev at lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
>
>
> --
> Anthony Minessale II ? @anthmfs ? @FreeSWITCH ?
>
> ? http://freeswitch.org/ ? http://cluecon.com/ ?
> http://twitter.com/FreeSWITCH
> ? irc.freenode.net <http://irc.freenode.net> #freeswitch ?
> _http://freeswitch.org/g+_
>
> ClueCon Weekly Development Call
> ? sip:888 at conference.freeswitch.org
> <mailto:sip%3A888 at conference.freeswitch.org> ? +19193869900
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20140312/48d66b2b/attachment-0001.html
Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-dev
mailing list