Weave Code
Laravel Better Temporary Urls Laravel Package
friendsofcat/laravel-better-temporary-urls
A Laravel package for better temporary URLs: generate signed, expiring links for routes and files with a cleaner API, configurable lifetimes, and sensible security defaults. A drop-in upgrade for Laravel's built-in temporary URL helpers.
Better Support for Temporary URLs in Laravel Filesystems
Frequently asked questions about Laravel Better Temporary Urls
- How do I install friendsofcat/laravel-better-temporary-urls?
- Install it with Composer using composer require friendsofcat/laravel-better-temporary-urls. As is Laravel package convention, the service provider is auto-discovered, so no manual registration should be needed. Expect a config publish step (php artisan vendor:publish) to expose the package's lifetime and signing settings. Adoption effort is measured in hours, not sprints.
- Which Laravel versions does laravel-better-temporary-urls support?
- Release 2.0.0 advertises Laravel 9 support and nothing else. If your fleet is on Laravel 10 or 11, treat that release as inert for you, and if you are on Laravel 8 or below the 0.x line is likely the only supported track. Always confirm by reading the require and require-dev constraints in the tag's composer.json rather than trusting the release note.
- What is the difference between this package and Laravel's built-in temporarySignedRoute?
- It is a drop-in upgrade that wraps or replaces Laravel's native temporarySignedRoute and URL::temporarySignedRoute behavior, giving you a cleaner API for generating signed, expiring links. The package adds configurable lifetimes and sensible security defaults on top of the framework helpers. It is designed for time-limited links such as downloads, invitations, password resets, webhook callbacks and one-time share links.
- Why did laravel-better-temporary-urls jump from 0.5.0 to 2.0.0?
- The version jump is a semver-major bump, but the changelog contains exactly one functional bullet with no upgrade guide, no breaking-change list and no deprecation notes. That usually means one of three things: support for older Laravel or PHP versions was dropped, the package was re-versioned to track Laravel majors with no API change, or there are genuine breaking API and config changes documented only in the diff. Assume dropped version support and breaking changes until the 0.5.0...2.0.0 compare diff proves otherwise.
- Is it safe to upgrade from 0.5.0 to 2.0.0 in production?
- Do not upgrade in place on a live branch. Pin your current 0.5.0, branch, bump to 2.0.0, and read the actual compare diff as the primary artifact since the release note bullet is a summary, not a contract. Diff the published config file and any migrations between tags, then run your full test suite plus an explicit test that generates a link on the old version and validates it on the new one, because cross-version link compatibility is the thing most likely to break silently.
- Does laravel-better-temporary-urls work with Laravel 10 or 11?
- Release 2.0.0 only advertises Laravel 9, so there is no stated support for Laravel 10 or 11. Rather than forcing it, either stay on 0.5.0 where it still works on your stack or evaluate alternatives. Verify with three independent layers of checks: Composer constraint resolution against your lockfile, framework-level behavior of the service provider and config merge, and behavioral tests around TTL boundaries and signature validation.
- How do I configure the expiry lifetime of temporary URLs?
- Lifetimes are configurable, and configuration is exposed through the package's published config file following normal Laravel package conventions. Publish the config and set your default and per-link lifetimes there. Bear in mind that the default TTL may have changed between 0.5.0 and 2.0.0, so diff the published config between the two tags before upgrading.
- How do I test temporary URLs generated by this package?
- Write feature tests that hit the signed route through Laravel's signed middleware so you exercise real signature validation rather than just asserting a string shape. Add explicit boundary tests for TTL expiry, checking that a link works just before expiry and fails just after it. If you are migrating between tags, also test that a link generated by 0.5.0 still validates under 2.0.0, since signature or payload changes would break outstanding links silently.
- Are the temporary URLs revocable or single-use?
- The package is positioned as an ergonomics and security-defaults improvement over Laravel's signed URLs, not as a revocation system, so assume links live until their TTL expires. Whether signature state is stateless (an HMAC over the payload using APP_KEY) or persisted in a database or cache makes a big difference to failure modes and scaling, so confirm that before relying on it. If it is stateless, APP_KEY rotation remains the only invalidation lever and will invalidate every outstanding link at once.
- Is laravel-better-temporary-urls actively maintained, and what are the alternatives?
- Maintenance is the biggest non-code risk here: the maintainer base is small, there is a single new contributor with one PR, and bus factor is a live concern given the security-sensitive surface of signature generation and TTL enforcement. Check the maintainer's response time on issues and security reports before committing. If the version fit is wrong or the risk is too high, keeping Laravel's native temporarySignedRoute helpers or staying on the 0.5.0 line are reasonable alternatives, especially if you isolate URL generation behind a thin internal adapter contract so it can be swapped later.
Weaver
How can I help you explore Laravel packages today?