History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XCF-2574
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Raghu Venkataramana
Reporter: Scott Lawrence
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
sipXconfig

Dial plan to require a permission for a non-gateway call does not work

Created: 2008-05-21 09:56   Updated: 2008-10-31 09:19
Component/s: dial plan
Affects Version/s: 3.10.1
Fix Version/s: 3.11.7

Original Estimate: 2 days Remaining Estimate: 2 days Time Spent: Unknown
File Attachments: 1. Text File 0001-XCF-2574-fix-generation-permissions-for-internal-rul.patch (20 kb)
2. Text File 0002-XCF-2574-fix-generation-of-hostMatch-in-authrules-fo.patch (18 kb)
3. Text File XCF-2574.patch (17 kb)

Issue Links:
Related
This issue related to:
XCF-1193 custom added permission represented a... Minor Open
 


 Description  « Hide
Attempting to create a rule that requires a permission to allow a call
to a destination that is not a gateway does not generate correct
configuration. Users sometimes request this in order to, for example,
require that even internal calls must be "from registered phones" (this
doesn't really require registration, but the effect is the same).

Configuration to generate the problem:

  Permissions
    Create a custom permission 'Station' - set to be enabled by default.

  Dial Plans
    Add a Custom Dial Rule, with settings:
        Enabled checked
        Name 'Extensions'
        Description 'Calls to internal extensions'
        Dialed Number
               Prefix ''
               and 3 digits
        Required Permissions
               Station checked
               (all others unchecked)
        Resulting Call
               Dial ''
               and append Entire dialed number
        Schedule Always
        No gateways

    Activate Dial Plans

The above should generate entries in mappingrules.xml (because there
is no gateway) and authrules.xml (because a permission is required).

The mappingrule entry that is generated now is:

  <mappings xmlns="http://www.sipfoundry.org/sipX/schema/xml/urlmap-00-00">
    ...
    <hostMatch>
      <hostPattern>${SIPXCHANGE_DOMAIN_NAME}</hostPattern>
      <hostPattern>${MY_FULL_HOSTNAME}</hostPattern>
      <hostPattern>${MY_HOSTNAME}</hostPattern>
      <hostPattern>${MY_IP_ADDR}</hostPattern>
      <userMatch>
        <!--Extensions-->
        <description>Calls to internal extensions</description>
        <userPattern>xxx</userPattern>
        <permissionMatch>
          <permission>perm_3</permission> <!-- INCORRECT -->
          <transform>
            <user>{digits}</user>
          </transform>
        </permissionMatch>
      </userMatch>
      ...

The line marked INCORRECT above should not be there at all.

The authrules entry generated by the above is:

  <mappings xmlns="http://www.sipfoundry.org/sipX/schema/xml/urlauth-00-00">
    <hostMatch>
      <!--to Pingtel-->
      <hostPattern>pingtel.com</hostPattern>
      <userMatch>
        <userPattern>xxx</userPattern>
        <permissionMatch/>
      </userMatch>
    </hostMatch>
    ...

which is incorrect because it does not require the configured
permission. The <permissionMatch/> element in the above should be:

  <permissionMatch>
    <permission>Status</permission>
  </permissionMatch>


 All   Comments   Work Log   Change History      Sort Order:
Scott Lawrence - 2008-05-21 09:58
it will be confusing (and the SIP error responses will have undeciferable names in them) if you don't fix XCF-1193 at the same time.

Damian Krzeminski - 2008-10-06 09:10
For internal rules: do not generate permissions in mappingrules.xml (since they are interpreted there as source permissions not destination permissions), but add entries in authrules.xml

This is a change compared to what it's implemented now: for internal rules we generate mappingrules.xml permission entry but no authrules.xml entries.

Laurentiu Ceausescu - 2008-10-16 10:02
I added permission entries for internal rules in authrules.xml and I removed them from mappingrules.xml.

Damian Krzeminski - 2008-10-16 15:39
This is probably my fault: some rules do need to behave as they used to (put permission elements in mappingrules but not in authrules).

I think we have to add another switch: source vs. target permission rule.

All rules (internal and not internal) are by default "target" permission rules. That means that they need "permission" elements in authrules and fallbackrules (if they are not internal) but never in mappingrules (if they are internal).

Some rules are "source" permission rules. Which means that they only need "permission" elements in mappingrules. Voicemail rules are the only once I can think of that has this property.

Please whenever possible add new tests instead of changing the old ones (cover all code paths: source/internal, target/internal, target/external).

Laurentiu Ceausescu - 2008-10-20 08:11
I added "isSourcePermission()" switch, to keep "source" permission for internal rules in mappingrules.xml.

Damian Krzeminski - 2008-10-22 14:33
some minor fixes to original patch, and a major fix for authrules generation - please review

Damian Krzeminski - 2008-10-22 14:35
Please configure custom rule and make sure that permissions actually work (iow: that you can make calls to internal destinations that have those permissions and cannot make calls to the ones that do not have them.)

Damian Krzeminski - 2008-10-31 09:19
http://sipxecs.sipfoundry.org/ViewVC/sipXecs?view=rev&rev=13862

XCF-2574 fix generation permissions for internal rules

Add 'targetPermission' property to dialing rules. Only rules with 'targetPermission' set generate
'permission' elements in (mapping|fallback)rules.xml files. All other rules generate permission
element in authrules.xml. At the moment only Voicemail related rules have 'targetPermission' set.

Until this change sipXconfig used to generate mappingrules.xml permission entry but no authrules.xml
entries for all internal rules, which made it impossible to configure custom internal rules that
http://sipxecs.sipfoundry.org/ViewVC/sipXecs?view=rev&rev=

In spite of the fact that we have no gateways we still need to match against SIP domain (and usual
suspects - hostname and IP address). Also userMatch requires that we use translated (target)
patterns, and not patterns dialed by the user.