Ya know someone did this 
Yeah it was just a few lines of sed to completely change over my module to ‘allowlist’. Even all the code behind modules are renamed. The biggest pain was remaking the repository.
Whoof, after an exercise in futility chasing down an errant ‘)’ I finally got the splicing into the dialplan working. I add two lines just above the label “gocall” which I think is the place to put the check to see if an outbound dialed number should be added to the allow list. If anyone has better ideas let me know.
1 Like
Only now just getting a chance to try this. You need to update how the AGI file is referenced. Change the module folder for the agi from agi to agi-bin and then reference the agi filename directly without a path. The module install process (you will need to install the module again) will automatically copy the agi and set appropriate permissions. This will allow it to work with fastagi when enabled.
1 Like
Thats cool – I figured there had to be some way FreePBX would support those AGI scripts and get them to the right directory.
I’ve updated the github repository with the changes for FastAGI
1 Like
Lorne, others – did you have any thoughts on whether it is worth me trying to contribute the module to FreePBX? I’ve got some ideas but other than that and checking for the installation of Contact Manager before trying to use it as an allowlist I’m pretty much done with all my ideas on this one.
SPAM call detection is something I want to look at as a separate issue, perhaps using some of the IVR ideas noted in this thread. I see that as not so much the responsibility of the allowlist module but rather of the destination it sends non-allowlisted callers to.
Thoughts?
I found it, thanks!
What is the best way to check if contact manager has been installed on a FreePBX system? I need to make sure that the checks do not blow up if it is not present.
Thanks!
I am trying to create a way for someone to hook into the [app-allowlist-check] routine so they can override the checks from the module with anything that they can think of – I added a channel variable “callerallowed” which if set to “1” upon entering [app-allowlist-check] would bypass all of the generating checking and let their custom dialplan override.
I though that FreePBX way of adding “#include => xxxx-custom” everywhere was the way this could be done – however since Asterisk checks the current context before looking into included ones this does not work. The custom dialplan isn’t evaluated until after the regular dialplan is.
That seems counter intuitive to anyone used to the way programming languages use include files so I suspect I am misunderstanding the entire xxx-custom approach that FreePBX uses.
What I am trying to do is give administrators a way to add extra custom allowlist checking rules via extensions_custom.conf – I hope there is a way to make that work.
One thing I had thought to try is do something like have the module write out the app-allowlist-check contect this way:
[app-allowlist-check]
include => app-allowlist-check-custom
include => app-allowlist-internal
[app-allowlist-internal]
auto generated dialplan logic goes here
Can anyone offer any tips or suggestions?
Thanks!
You want a dialplan hook, which currently rely on the deprecated macro application, but you can be the first to create a gosub hook:
https://issues.freepbx.org/browse/FREEPBX-19656?jql=text%20~%20"Replace%20macro%20gosub"
In your case you don’t need the macro part at all, just use gosubif and check for the existence of the context. Not tested:
exten => s,n,GoSubIf($[${DIALPLAN_EXISTS(app-allowlist-check-predial-hook,s,1)}]?app-allowlist-check-predial-hook,s,1())
1 Like
You could define contact manager as a dependency of allowlist, that is a pretty workable solution as it’s OSS and would be available for all installs. In module.xml something like:
<depends>
<module>contactmanager</module>
</depends>
Otherwise, I would expect method_exists or class_exists would do it as well, tho I can’t recall ever seeing an example of that.
1 Like
Look at certman and how it checks for the firewall module.
1 Like
I got the gosub dial plan hook implemented – worked like a charm!
Checking for the Contact Manager presence turned out to be as simple as a try…catch block around the search – get an exception, its not there and so return false - number not found.
1 Like
Hi Mitch
I’ve been thinking about how an admin might accidentally enable the allowlist without realizing the consequences. I think at the moment, all that’s required to enable this system wide is to set a ‘Destination for Non AllowListed Calls’, is that correct? Likewise, unset to disable the allowlist?
I wonder if it would not be more in keeping with the rest of the GUI UX to have a toggle for each inbound route to enable/disable allowlist for the route. Thoughts?
1 Like
Lorne,
That’s interesting that you are thinking this – I had the same idea after I realized that the original blacklist behavior I copied over would be a potential land mine for the operator – download and enable the module and suddenly wonder why the phones all stopped ringing.
I changed the behavior to what you describe, download and enable the module and it does absolutely nothing to your calls until you specify a destination for non-allowed-listed calls.
After that I thought about doing it by trunk as I have a use case that actually requires that – I have a hamshackhotline.com trunk that is connected to a VoIP network of only licensed amateur radio operators - no need to spam check them. That’s why I ultimately went with the gosub dialplan hook so I could do custom allowing of calls.
I later thought about doing it by did – entering them in the database just like numbers except with a /did/ prefix so I could allow entire dids with one entry. I punted back to the gosub dialplan because I realized my php and web programming skills aren’t far enough along to know how to do it in a 'best practice" fashion. I never thought about it for routes (aren’t those about the same thing though?)
I agree that it should be consistent with the rest of the FreePBX gui – so if you can point me to one of the web pages you are referring to so I can take a look at how the presentation of the toggling is done I’ll check it out. If I have a good reference I can probably make it work without weaving too much of a rats nest in the code.
I’ve been focused on setting up a spam detection ivr and that has me looking at follow me, voice mail and presence to handle calls that pass spam detection – quite the rabbit hole LOL.
So just give me an idea what to look at in the FreePBX that you think represents the consistency you are looking for and I’ll see if I can put it together.
Thanks!
I was thinking like is done for superfecta and CID lookup on an inbound route. The dialplan is only written to the inbound route where it’s specifically enabled.
That is an interesting tradeoff – either write the dialplan all the time and turn it on an off with a database flag or only write it when enabled and require a reload.
I’ll take a look at how superfecta does it.
OK I think I see what you are getting at – it appears that superfecta inserts the enable/disable buttons on to the route configuration web page. I’ll have to figure out what sort of sorcery is involved, but I think that will work for allowlist. Any hints you can share will be greatly appreciated!
Thinking it’s best to look at cidlookup, Superfecta is a bit special. This file controls the gui elements on the inbound route, other tab
/var/www/html/admin/modules/cidlookup/views/coreDIDHook.php