[Rtir] Modify RTIR_FindIP.pm script to filter IPs

[David Moreau Simard]

I have the habit of extending RT through callbacks, but not extending 
extensions (!).
Would that go under local/plugins/RT-IR/local/lib/RT/Action/RTIR_FindIP.pm ?

I might review the code some more in the near future but either way, I 
kept it really quite simple for the time being.
Let's pretend a dummy example and say I don't want RT-IR to map anything 
to the IP custom field by itself outside of 192.168.x.x and 127.0.0.x:

etc/RT_SiteConfig.pm:
Set(@RTIR_IPv4_range_preference, qw (
         192.168.0.0/16
         127.0.0.0/24
         )
);

local/plugins/RT-IR/lib/RT/Action/RTIR_FindIP.pm:
use Net::IP::Match::Regexp qw( create_iprange_regexp match_ip );

# It's possible for a user to exclude IP addresses that aren't mapped in 
the configuration
my @IPv4_range_preference = RT->Config->Get('RTIR_IPv4_range_preference');
my $range_preference_regex;
if(scalar(@IPv4_range_preference) != 0) {
         $range_preference_regex = 
create_iprange_regexp(@IPv4_range_preference);
}

[...]

while ( $content =~ m/$IP_re/go ) {
         if ( $1 && defined $2 ) { # IPv6/mask
             my $range = $2 == 128 ? $1 : (Net::CIDR::cidr2range( 
"$1/$2" ))[0]
                 or next;
             $spots_left -= $self->AddIP(
                 IP => $range, CustomField => $cf, Skip => \%existing
             );
         }
         elsif ( $1 ) { # IPv6
             $spots_left -= $self->AddIP(
                 IP => $1, CustomField => $cf, Skip => \%existing
             );
         }
         elsif ( $3 ) { # IPv4
             # If we have user preferences, match the IP against them
             if($range_preference_regex ne '') {
                 if(match_ip($3, $range_preference_regex)) {
                     $spots_left -= $self->AddIP(
                         IP => $3, CustomField => $cf, Skip => \%existing
                     );
                 }
             } else {
                 $spots_left -= $self->AddIP(
                     IP => $3, CustomField => $cf, Skip => \%existing
                 );
             }
         }
         elsif ( $4 && defined $5 ) { # IPv4/mask
             # If we have user preferences, match the IP against them
             if($range_preference_regex ne '') {
                 if(match_ip($4, $range_preference_regex)) {
                     my $cidr = join( '.', map $_||0, (split /\./, 
$4)[0..3] ) ."/$5";
                     my $range = (Net::CIDR::cidr2range( $cidr ))[0] or 
next;
                     $spots_left -= $self->AddIP(
                         IP => $range, CustomField => $cf, Skip => 
\%existing
                     );
                 }
             } else {
                 my $cidr = join( '.', map $_||0, (split /\./, $4)[0..3] 
) ."/$5";
                 my $range = (Net::CIDR::cidr2range( $cidr ))[0] or next;
                 $spots_left -= $self->AddIP(
                     IP => $range, CustomField => $cf, Skip => \%existing
                 );
             }
         }
         return 1 unless $spots_left;
     }


*David Moreau Simard*

On 12-06-19 5:39 PM, Kevin Falcone wrote:
> On Tue, Jun 19, 2012 at 12:02:21PM -0400, David Moreau Simard wrote:
>> We're giving RTIR v3.0RC1 a test drive and I added a layer of
>> regular expression to prevent mapping IPv4 addresses to custom
>> fields if it's CIDR range is not specified in the RTIR_Config.pm.
>> The modifications adds a dependency (yikes) to Net::IP::Match::Regexp.
>>
>> It works pretty well. If you are interested, I'd be glad to
>> contribute the modification back to github or other means if you are
>> interested.
>>
>> I tried to figure out which branch v3.0RC1 is based off of but I got
>> lost quickly.
> The branch is 2.9-trunk which will become 3.0-trunk when we're ready
> for the final release (so 2.5-trunk was the dev series for 2.6-trunk
> and over on RT we're working on 4.0-trunk and will eventually have
> some 4.1 releases while we get ready for 4.2-trunk, etc).
>
> https://github.com/bestpractical/rtir/tree/2.9-trunk
>
> I'm not entirely sure if this is best served as a merge into core or
> as an extension, but the code would be interesting to see.
>
> -kevin
>
>
> _______________________________________________
> Rtir mailing list
> Rtir at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir