--- title: "Installation" manual: "HTTP Guard" version: "main" permalink: "https://docs.typo3.org/permalink/netresearch/nr-http-guard:installation@main" source: "Installation/Index.rst" rendered: "2026-10-18T14:31:38+00:00" --- # Installation {#installation} Install and activate the extension to protect existing calls through TYPO3's registered `RequestFactory` automatically. The default `enforce` mode blocks private, loopback, cloud metadata and special-purpose destinations, including URLs supplied by users, imports or external payloads. No application rewrite or endpoint configuration is required to enable this default protection. ## With Composer {#installation-composer} Install the published 0.1 series from [Packagist](https://packagist.org/packages/netresearch/nr-http-guard): **Installation in a TYPO3 project** ```bash composer require netresearch/nr-http-guard:^0.1 vendor/bin/typo3 cache:flush vendor/bin/typo3 http-guard:config-check vendor/bin/typo3 http-guard:doctor ``` Composer registers the extension automatically. After rebuilding caches, ordinary RequestFactory calls use the protected default. Version 0.1.4 is an alpha for evaluation. Review the project's resolved dependencies against [Requirements](https://docs.typo3.org/permalink/netresearch/nr-http-guard:installation-requirements@main) before deployment. The extension does not require an additional `netresearch/http-guard` package. ## Classic installation without Composer {#installation-classic} Install `nr_http_guard` from the [TYPO3 Extension Repository](https://extensions.typo3.org/extension/nr_http_guard). Activate it in the Extension Manager and rebuild caches. This enables default protection without a custom policy. The TER package contains extension files directly at its root. The source archives from [GitHub releases](https://github.com/netresearch/typo3_http_guard/releases) contain one `nr-http-guard/` directory. Neither archive includes an additional vendor directory. The official TYPO3 installation supplies Guzzle, PSR components and Symfony. 1. Prepare a supported classic TYPO3 installation. The official Core archives tested at 13.4.36 and 14.3.8 contain Guzzle 8.2.0, Promises 3.0.2 and PSR-7 3.1.0, within the supported ranges. 1. Install from TER or import its extension ZIP using the Extension Manager's upload function. For a manual installation from a GitHub release, extract the source archive and copy the **contents** of its `nr-http-guard/` directory into `typo3conf/ext/nr_http_guard/`. The extension's `composer.json` must be directly inside that target directory. Activate the extension in the Extension Manager. 1. Rebuild the system and dependency injection caches. Retain the supplied `composer.json`: TYPO3 needs its metadata even in classic mode and registers both embedded PHP namespaces itself. 1. Run diagnostics. Custom policy configuration is optional for public requests; internal integrations need explicitly bound endpoint clients. In classic projects, the CLI entry point is usually `typo3/sysext/core/bin/typo3`. The actual path depends on how the project links the Core. **Diagnostics for a classic installation** ```bash php typo3/sysext/core/bin/typo3 cache:flush php typo3/sysext/core/bin/typo3 http-guard:config-check php typo3/sysext/core/bin/typo3 http-guard:doctor ``` The official guides explain [classic TYPO3 installation using archives](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/Administration/Installation/ClassicMode/TarballZip.html) and an extension's [composer.json for classic compatibility](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/ExtensionArchitecture/FileStructure/ComposerJson.html#ext-composer-json-classic-compatible). ## Requirements {#installation-requirements} Composer supports TYPO3 `^13.4.36 || ^14.3.8` and PHP `^8.2`. PHP must also meet the selected Core's requirements. Compatible updates within these ranges do not require a new HTTP Guard release. The runtime checks the actual Core parent API and SDK capabilities and rejects incompatible APIs before a native send. | Guzzle | Promises | PSR-7 | | --- | --- | --- | | `^7.15.2` | `^2.5.1` | `^2.13.0` | | `^8.2` | `^3.0.2` | `^3.1` | The minima provide the required transport APIs. Composer must resolve a compatible complete graph within the supported majors. Each transfer lease allocates at most one native handle; hidden SDK retries cannot bypass the per-attempt policy boundary. The fixed Core/SDK fixtures record reproducible tests at specific versions, not the full set of installable dependencies. Current compatibility checks are described in [Semantic support and recorded proof](https://docs.typo3.org/permalink/netresearch/nr-http-guard:verification-semantic-support@main). Historical kernel coverage spans PHP 8.2–8.5; future compatible PHP versions are permitted but are not claimed as already tested. Classic extension metadata permits TYPO3 13.4.36–14.3.99 and PHP 8.2.0–8.99.99. The classic TYPO3 upper bound is narrower than the Composer ranges and currently targets the 13.4/14.3 LTS branches. The contiguous TER notation cannot express the separate Core 14 minimum: the runtime rejects Core 14.0–14.2 and 14.3 patches before 14.3.8. Core's own PHP requirements and the same runtime checks apply. The controlled transport requires `ext-curl`, the `curl_multi_exec` function and, for its functionality, at least libcurl 7.59.0. This minimum version is not a security assessment. Install operating system and PHP security updates according to the respective vendor's guidance. The process needs access to its controlled DNS servers or explicitly configured static host entries. > [!WARNING] > HTTP, HTTPS, ALL and NO_PROXY process variables are conservatively > rejected regardless of case. This includes `NO_PROXY=*`. > A corporate proxy requires a separately qualified adapter; this > version does not support proxy operation. ## Verify the installation {#installation-check} `config-check` validates the schema and reports the policy revision. `doctor` checks the mode, registry, Core and SDK versions, cURL capabilities and proxy variables. Neither command sends HTTP to a target. Exit code 0 from `doctor` confirms the supported protected mode. Exit code 2 identifies an explicitly unprotected mode; exit code 3 indicates invalid configuration or an unsupported capability. See [Diagnostic commands](https://docs.typo3.org/permalink/netresearch/nr-http-guard:operations-diagnostics@main) for details. After activation, test a controlled public target followed by a forbidden internal target. The latter must leave the target's TCP and HTTP counters unchanged. Project tests must call the actual RequestFactory or bound client in use. Successful diagnostics do not qualify an arbitrary SDK path. ## Updates and removal {#installation-update} Update the project dependency lock within the supported ranges. A compatible dependency patch or minor does not require updating the extension. Review extension and address-rule updates separately when those components change. Rebuild caches and restart long-lived workers after each policy or package change. Existing clients retain their immutable configuration snapshot until they are replaced. Before removing the extension, adjust bound clients and service aliases in the project. Deactivation removes the additional protection from the TYPO3 HTTP path. Deployment and rollback steps are described in [Rollout in an operator project](https://docs.typo3.org/permalink/netresearch/nr-http-guard:operations-rollout@main) and [Rollback](https://docs.typo3.org/permalink/netresearch/nr-http-guard:operations-rollback@main).