Basic Firewall 1.0.0-rc.3

Third release candidate for 1.0.0. Published as a GitHub pre-release, so
the releases/latest/download URL does not serve it; install it by its own URL.
The headline is #30: rules now see the path of a directly requested PHP file
(wp-login.php, xmlrpc.php, /wp-admin/*.php), which they did not before.
What changed since 1.0.0-rc.2 is below.

Changed

• Requires and bundles kanopi/firewall 2.34.0 (was ^2.33.2). The release
  zip bundles 2.34.0, namespace-scoped. It adds global.path_source and
  global.base_path, which the fix below uses
  (kanopi/firewall#414,
  #415), and stores a direct
  file's URL in block records without a trailing /.

• bot equals true now matches Nikto. 2.34.0 requires
  matomo/device-detector ^6.5.2, which adds Nikto's default agent to the
  curated bot database. The rule screen, README and readme.txt no longer list
  Nikto among what bot misses. sqlmap, curl and python-requests still need
  automated.

• With WordPress in its own directory (Site Address /, WordPress Address
  /wp), WordPress's own files are matched with that directory:
  /wp/wp-login.php, /wp/wp-admin/edit.php. The front controller is the web
  root's index.php, so there is no base path to strip, and stripping /wp
  would need the raw-URL reading this release removes. Rules on those files
  need the prefix. Site Health recommends it when a rule or an enabled preset
  names them without it, and the Test screen defaults to /wp/wp-login.php.

• A rule that matched path / no longer catches every directly requested
  file. Before this release a direct wp-login.php, xmlrpc.php or
  /wp-admin/*.php request reached the rules as /, so path equals / (or a
  pattern that only / satisfied) matched all of them. It now matches the
  front page only. Check any rule written against what the old behaviour
  logged.

Fixed

• Rules now see the path of a directly requested PHP file (#30). WordPress
  serves wp-login.php, xmlrpc.php, wp-cron.php, every /wp-admin/*.php
  screen and custom endpoints in the site root from the file itself rather than
  through index.php, and for those the library's path was /. A
  /wp-login.php rate limit never counted a login, a rule on /wp-admin or
  /xmlrpc.php never matched, a negated path condition matched every such
  request, and the log and block records said path: /. The compiled
  configuration now sets global.path_source: script_name, so path is the
  file the web server ran, on the wp-config.php path, in the mu-plugin
  (including logged-in requests deferred to plugins_loaded) and on the Test
  screen. global.base_path is compiled for a subdirectory install from the
  Site Address, or from the network's path on a multisite network, and the
  compiled file is rebuilt when either address changes. A challenge on a
  direct file posts its answer under the front controller's directory, through
  a compiled challenge.submit_url, so an admin screen's challenge is
  recognised. A Site Health check, Basic Firewall request path, asks the
  library what a direct wp-login.php request resolves to under the compiled
  settings. It is critical if path_source: script_name is missing, or if the
  login page or a page resolves to anything but itself. Schema routine 10
  recompiles every site on update.

  Because path is the file the web server ran rather than the URL as typed,
  a spelling the server normalises -- /./wp-login.php, /%77p-login.php,
  //wp-login.php, /x/../wp-login.php, /wp-login.php;x -- is matched as
  /wp-login.php, so none of them gets past a rule or rate limit on it.