Release/api key verification middleware - #32
Conversation
IndexNow search engines verify ownership by requesting a text file
at /{apiKey}.txt whose content matches the configured API key.
Instead of requiring users to manually create and maintain a static
file, this PSR-15 middleware serves it dynamically from the extension
configuration. Once the API key is saved in extension settings, the
verification file is immediately available.
The middleware runs early in the frontend pipeline (before site
resolution) and only matches root-level .txt requests where the
filename equals the configured key. All other requests pass through
unchanged. Responses include a 24-hour cache header.
Also updates README to reflect that manual file creation is no longer
needed.
- Added support for resolving site-specific paths in the API key verification middleware. - Replaced generic exception handling with `ApiKeyNotAvailableException`. - Enhanced response headers to include `Content-Length` for better caching.
sfroemkenjw
left a comment
sfroemkenjw
left a comment
There was a problem hiding this comment.
Hi, thanks for the PR! While the concept of dynamically serving the verification key is great, handling this via a global middleware and a single Extension Configuration introduces a couple of architectural bottlenecks, especially since TYPO3 is inherently multi-domain. A single value in the Extension Configuration restricts the entire instance to just one IndexNow API key, whereas a multi-site setup requires a unique key per domain. We should leverage Site Settings instead, allowing users to define the API key per site. Additionally, a global middleware runs on every single request across the entire instance, adding unnecessary overhead, while a native Route Enhancer would allow the endpoint to be handled and cached efficiently within TYPO3's core routing framework.
Since you just bumped the version to 1.0.0, introducing these structural breaking changes later on will become significantly harder, which is why I originally preferred using 0.0.9 to keep these architectural options open. If we stick to a middleware for now, it should at least be registered after the site-resolver middleware so we can access the current site configuration via the request attribute to fetch a domain-specific key, but refactoring this towards Site Settings and native routing right now would be the far cleaner, future-proof path. What do you think about adjusting this before we lock it down in a major release?
Updated Documentation Block Co-authored-by: Stefan Frömken <123929835+sfroemkenjw@users.noreply.github.com>
Co-authored-by: Stefan Frömken <123929835+sfroemkenjw@users.noreply.github.com>
… site settings - Deleted `ApiKeyVerificationMiddlewareTest` along with its test cases. - Updated `ApiKeyVerificationMiddleware` to use site settings for retrieving the API key instead of the `ExtConf` class. - Streamlined path extraction and request handling for better maintainability.
- Added strict type declarations to `RequestMiddlewares.php`. - Simplified middleware configuration by removing unnecessary `before` and `after` keys. - Removed unused `apiKey` setting from `ext_conf_template.txt`.
…ension - Introduced `config.yaml` for the default IndexNow set. - Added localized labels and descriptions for IndexNow API key configuration. - Defined API key setting with category, type, and default value.
- Added Hoja Mustaffa Abdul Latheef as co-author in `composer.json` and `ext_emconf.php`. - Updated the extension version in `ext_emconf.php` to 0.0.10.
… test coverage - Added unit test execution step. - Introduced functional test scenarios for MariaDB, SQLite, and Postgres.
…est cases - Deleted outdated functional tests for `ApiKeyVerificationMiddleware`.
2 participants
No description provided.