- Can I install gremo/hmac-authentication-bundle in a Laravel application?
- Not in any practical sense. It is a Symfony bundle that registers a firewall listener and depends on Symfony's DependencyInjection, EventDispatcher, and HttpFoundation contracts, none of which map onto Laravel's middleware pipeline or guard system. You would have to pull in Symfony components and hand-wire a listener into Laravel's kernel, replacing what should be a small middleware with a permanent dependency. Composer require will succeed or fail on version constraints, but neither outcome gives you a working Laravel integration.
- What does gremo/hmac-authentication-bundle actually do?
- It adds HMAC request signing and verification to a Symfony API: clients sign outgoing requests with a shared secret, and the bundle validates the signature on the server side. It plugs into Symfony's security layer so protected routes reject unsigned or tampered requests. The reusable part of the package is really the canonicalization scheme, meaning which request components get signed, in what order, and with what encoding.
- Does this package support Laravel 10, 11, or 12?
- No. There is no Illuminate\Support\ServiceProvider, no publishable configuration, and no facade, so there is nothing for a modern Laravel app to boot. The package targets Symfony and its last release was June 2019, well before Laravel 10 through 12 existed. Any claim of Laravel support would require a fork that reimplements the integration layer from scratch.
- What exactly goes into the HMAC canonical string?
- That is the single most important question to answer before adopting or copying the logic, and you must read it byte for byte from the source. Look specifically for whether the HTTP method, path, query string, body hash, Content-Type, timestamp, and nonce are all covered, plus the exact separators and encoding used. A scheme that signs the path but omits the query string or body leaves room for silent tampering. Document the string construction precisely, because that is the interoperability contract your clients will depend on.
- Does the bundle protect against replay attacks?
- You need to verify this in the source rather than assume it. Meaningful replay protection requires a timestamp window check plus a nonce store with a TTL at least as long as that window, and both must be enforced. If the package only validates a signature, a captured request stays valid forever. Any reimplementation should use a configurable window, for example plus or minus 300 seconds, backed by a Redis nonce cache.
- How do I add HMAC request signing to Laravel without this package?
- Extract the canonicalization spec and write a first-party middleware of roughly 150 to 300 lines. The flow is verify the signature with hash_hmac, compare using hash_equals for constant-time safety, check the timestamp against your window, check the nonce against a cache with a matching TTL, then resolve the client secret and attach an authenticated principal to the request. Pair it with a guard or a Request::setUserResolver call so existing policies and gates keep working unchanged.
- Is the bundle still maintained, and does it run on PHP 8?
- The last release was 2019-06-05, so it predates Symfony 5, 6, and 7 as well as the PHP 8.x line. Its Composer constraints very likely conflict with a modern stack, and you should check the require block in composer.json before considering anything else. Even if it installs, you inherit deprecated API usage that would need rewriting anyway.
- Is it safe to depend on unmaintained code for security-critical HMAC verification?
- Treat it as a supply-chain liability rather than an asset. HMAC verification is exactly the class of code where a subtle flaw, such as a naive equality check, missing replay protection, or an unsigned body, is silently exploitable, and this repository has five stars, zero dependents, and no visible external audit. The mitigating factor is that request signing is a small, well-understood primitive, so reimplementing it removes nearly all of the risk. The danger lives in the dependency, not in the problem.
- How should I store and rotate per-client API secrets in Laravel?
- Keep secrets server-side in an api_clients table, encrypted at rest with Laravel's encrypter or a secrets manager, and never in configuration files committed to the repository. Build in key versioning so a client can hold an old and a new secret simultaneously during rotation, with the verifier accepting either until the overlap window closes. Rotation should be an explicit, auditable operation rather than an update-in-place that silently breaks every client at once.
- How do I test signed HMAC requests in Laravel feature tests?
- Generate the signature inside the test using the same canonicalization helper your middleware verifies with, then send the request with the relevant headers and assert the response. Cover the negative cases explicitly: a tampered body, an expired timestamp, a reused nonce, an unknown client id, and a signature computed over the wrong query string. Those failure tests are what prove the middleware actually protects endpoints rather than just parsing headers. Because you own the code, you can also unit test the canonical string builder in isolation.