If an IP is in the Administrator IP Whitelist
AND the administrator IP whitelist feature is enabled in the Configure WAF page THEN the IP is already exempt from blocking. Therefore there is no integration to be written.
The reason of existence for the "Exceptions from blocking" area is two-fold:
- Not all exempt IPs must have access to the administrator section of your site. For example, a third party service which scans your site for vulnerabilities must never be blocked even though it's seen to be attacking your site, but must not be allowed to enter the administrator area of the site.
- Exempting IPs must be possible without limiting access to the administrator backend. For example, you may have a Publisher user who's only allowed to write / edit / publish articles from the frontend. You don't want her to be blocked by Admin Tools when she's editing an article with content that might be interpreted as an attack but you don't want her to have access to the backend area either. This is what you want to use it for.
Since you are not using the IP whitelist feature you should not put any IPs in that list. The only reason we are not hiding that list when you disable this feature is the chicken and egg problem: if you enable the administrator IP whitelist before entering any IPs you are locking yourself out of the site, in which case you could not enter any IPs in the whitelist.
What you should do instead is keep an external list of IPs and the corresponding persons / entities e.g. in an Excel file or a Google Sheets document. If you're using a spreadsheet it's easy to use the CONCATENATE() function to generate the up-to-date "Exceptions from blocking" list.
Why not enable a direct integration between the IP Whitelist list and the "Exceptions from blocking" area?
Performance. All of the WAF settings are loaded from the database using one database query that loads one database row from a table that contains only one database row. That's a very fast operation that takes about 0.5 milliseconds. Loading IPs from the IP Whitelist table takes about 30 milliseconds when you have a dozen or so rows, i.e. it's 60 times
slower. It may not seem that much but when you consider that barebones Joomla renders a page in 300 milliseconds you realize that we're talking about a 10% impact over the system's baseline page load time.
Taking into account 1. how many people complain about performance 2. how many people get confused about the two features and 3. the on-screen and the documentation information we conclude that the current implementation is the optimal one.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!