[Freeswitch-dev] Difference of behaviour between apply-acl profile parameters
Anthony Minessale
anthony.minessale at gmail.com
Wed Mar 12 17:42:04 MSK 2014
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> 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.orghttp://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>
> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
>
> FreeSWITCH-dev mailing listFreeSWITCH-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> 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
>
>
--
Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞
http://twitter.com/FreeSWITCH
☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
<http://freeswitch.org/g+>*
ClueCon Weekly Development Call
☎ sip:888 at conference.freeswitch.org ☎ +19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20140312/246fff0c/attachment-0001.html
Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-dev
mailing list