A couple of years ago I documented our hack that is used to get Paxton Net2 to send messages when doors are opened into Slack, recent changes to Net2 break this and require some changes;
The endpoint changes from
Most operating systems provide a 'hosts file', a simple way of hardcoding a hostname to an IP address, negating the need for a DNS lookup - this allows you to hijack traffic intended for somewhere else.
You'd think by adding the following line to C:\Windows\System32\Drivers\etc\hosts, we can redirect this traffic to a server of our choice as before;
10.0.7.30 ws.textanywhere.net 10.0.7.30 www.textapp.net
However, this doesn't appear to work now. It seems that a DNS lookup isn't being performed (or if it is, the result is cached for a long time) but it seems that the IP is hardcoded in the Net2 software, therefore you'll need to use
netsh to remap this;
netsh interface portproxy add v4tov4 listenaddress=126.96.36.199 listenport=80 connectaddress=10.0.7.30 connectport=80
The result is the same, the traffic will reach your own server (in this case
See what's being sent
If you're just looking for advice on how best to repurpose hardcoded SMS notifications then see my original post which goes into detail about the best way to do this.
If, however, you're looking to use this with Net2 the actual variables have changed, but the only one you need to worry about is
body (note it no longer has a capital B) if you want to authenticate the request you should now use
password instead of
It works, again!
Why did this change?
I don't know, the pessimist in me would worry it's because someone found this little hack and didn't like it - because the old SMS endpoint still works, so it seems odd to change it and even odder to change it to a static IP address.
But, more importantly there's nothing I do here that can't be done with the Net2 API - and if I knew how to write anything in .net I'd do it that way!
I really want to do more with the dedicated net2 API, if I could find a way to hook into that with a script in Python or Node that just passed all the events across into 0MQ or redis or something that'd be perfect, either that or if Paxton would add HTTP POST to their action types in Triggers & Actions!