[sr-dev] extend check_blacklist() in userblacklist module

[Henning Westerholt]

On Monday 18 October 2010, Nicolas Rüger wrote:
> [..]
> I'd like to add some functionality to the userblacklist module and
> therefore I'd like to modify the function
> 
>   check_blacklist ([string table])
> 
> because I need a check for the CALLER's URI _instead_ of the CALLEE's URI.

Hello Nicolas,

i understand. At the moment this function does not support parameters, but 
patches are of course welcome. :-)

> I want to change that for me, as I do deal with SPIT-prevention and I need
> a global_list to be able to block or delay some caller's URIs globally and
> whitelist others (like hospitals and stuff) for incoming calls.
> [..]
> I had a look at "userblacklist.c" and I guess that's the one to patch. My
> idea is to implement the changes and name the method "check_blacklist1()".
> 
> Here it seems the the URI that's checked is stored in "req_number".
> 
>  [...]
> 
>  if ((parse_sip_msg_uri(msg) < 0) || (!msg->parsed_uri.user.s) ||
> (msg->parsed_uri.user.len > MAXNUMBERLEN)) { LM_ERR("cannot parse msg
> URI\n");
>          return -1;
>      }
>      strncpy(req_number, msg->parsed_uri.user.s, msg->parsed_uri.user.len);
> 
>  [...]
> 
> 
> I guess I have to change "msg->parsed_uri.user.s" to something that returns
> the CALLER instead of the CALLEE!?

You could indeed change the  c-code like this. 

> I had a look at the struct "sip_uri" (in msg_parser.h) because that's the
> type of variable "parsed_uri" and found the following...
> [..]
> So user is just a string (pointer to first char + length) and so it seems I
> have even to replace "parsed_uri" by something else.
> 
> Then I had a look to struct "sip_msg" (in msg_parser.h) as it's the type of
> "msg" and next level of abstraction. There I found...
> [..]
> Another idea is to extend the parameter array of "check_blacklist()" so
> that one can pass the URI which has to be checked as an extra parameter.
> 
> What do you think is the better way???

I'd think that adding functionality to parse arbitrary parameter is the better 
and more flexible way instead of the req_number change you proposed above. 
Take a look to the check_userblacklist functions to get some ideas for the 
implementation.

> Furthermore I need a function that checks the global list for whitelisted
> entries.
> 
> The flag "whitelist" is already present but there's no method to query it,
> as "check_blacklist()" returns true, when the prefix is whitelisted and
> the same when it's not on the list (so there's no way to distinguish
> between both possibilities yet)

Maybe you would like to add some functionality like the check_userwhitelist 
functionality, for the check_blacklist function?

Regards,

Henning