This is something that I discovered while chasing after the problem I reported in my previous support ticket involving the Events Booking extension which was issuing a POST request with a 'null' value for Itemid. I was mystified by the observation that I was unable to replicate the problem when I was at home - and using my home WiFi - but the problem appeared for everybody else who I asked to test it from their locations, appeared on my own devices when I left the house and used a coffee shop's WiFi and/or Cellular, and finally when I used the Opera Browser with its VPN to access the site. I finally realized that the reason I couldn't easily replicate the issue from my home was that all my devices present the same IP address to the site - the router's external IP address - and that I had put that address in the "Site IP Allow List" in Admin Tools.
This was a somewhat unexpected effect of putting that IP address into the "Site IP Allow List", which I'd done to prevent me from getting locked out of the site if I mistyped the secret string when attempting to access the site backend. I had (naively?) thought that was the primary purpose of the "Site IP Allow List". I have thought about this quite a bit for the past 24 hours, trying to imagine whether you intended that list to allow just about anything to not be blocked by Admin Tools if the IP address appears in that list. Taking you at your word - that it is better to ask than to presume - I'm asking.
Is the intended behavior that any request that comes from an IP address in the "Site IP Allow List" be left unexamined and unblocked or should the POST request with suspicious core parameters have been blocked even though my IP address is in the "Site IP Allow List"??
thanks
