When receiving POST callbacks to my server endpoint from FlightXML for incoming flight alerts, I want to authenticate the request so that I know it is coming from FlightAware rather than just blindly trusting incoming POST data.
Any suggestions on how I could do that? User-Agent could easily be spoofed. Can the remote IP posting to my server be relied on to stay constant, or are there a number of IPs that could post to me?
In the short term the best option is probably checking the remote IP.
Our current IP ranges are:
216.52.171.64/26
70.42.6.128/25
2600:0C13:1002:0004::/64
72.251.200.64/26
89.151.84.224/28
We’ve discussed using client-side SSL certificates in the future but have no planned implementation date.
Thanks, I’ve implemented remote IP checking for now.
Hi FlightAware,
It appears your IP address ranges have changed without warning. My checks for trusted hosts for posting alert callbacks are now failing. Can you please provide a complete list of your updated server IPs?
Thanks!
No change, the hosts delivering alerts are still in the netblocks above.
Where are you seeing the alerts posted from?
Which account do you have your FlightXML alerts set up on?
Thanks for the response. You know what, you’re right – the ranges haven’t changed. What did change is that the server is posting from the IPv6 address and I no longer see any of the IPv4 addresses. I hadn’t implemented the IPv6 range checking correctly. That switch over to IPv6 must have happened recently…
If your alert endpoint was using a DNS hostname and you recently added an “AAAA” (IPv6) address to it, then that might explain why you’re now getting POST requests there. If you wish to ensure that you only receive the POST requests via IPv4, then ensure that you’ve registered an endpoint that uses a hostname that only contains “A” (IPv4) records. A hostname that contains both “A” and “AAAA” records might receive requests from either, depending on the network routing priority at the moment.