- How do I install clarkewing/handoff in a Laravel application?
- Install it with composer require clarkewing/handoff, then publish the package config so config/handoff.php exists in your app. The package ships a service provider and route, so Laravel package discovery should register them without manual wiring. Set your handoff host and environment-specific domain values before testing the route. Confirm the exact publish command and any migration steps in the README for the version you pin.
- Does clarkewing/handoff support Laravel 10, 11, and 12?
- The package is expected to target modern Laravel on PHP 8.1 or newer, but the exact version matrix is not verified in the assessment. Check composer.json constraints for Laravel 10, 11, or 12 support before planning an upgrade. Running handoff hosts on divergent Laravel majors is an integration risk even if the package itself supports both. Pin a release whose constraints match every application in the handoff chain.
- What is the /handoff domain constraint in clarkewing/handoff and how do I configure it?
- Version 0.2.0 constrains the /handoff route to a configured domain instead of matching it on any host. That is a sensible security default, but it can silently break an existing install that relied on broader route matching. Set the domain per environment in config/handoff.php and verify it behaves correctly behind proxies and load balancers. Check whether the constraint fails closed when the value is missing before rolling it out.
- How does clarkewing/handoff secure handoff tokens, including TTL, single use, and replay protection?
- Handoff relies on signed URLs, so the core protections are signature validation and a short time to live. For the guest login flow, confirm single-use enforcement, replay protection, and domain or audience binding in the version you deploy. The assessment flags session minting from an unauthenticated entry point as the highest-risk surface in the package. Review the source or changelog rather than assuming the defaults are strict.
- Do I need a shared session driver such as Redis or the database for cross-domain handoff?
- Yes, cross-domain handoff assumes participating applications share a session backend, typically Redis or a database driver. Per-host file sessions or isolated cache stores produce login loops that look random and are difficult to debug. Confirm cookie domains, HTTPS everywhere, and trusted proxy headers are consistent across all hosts. If sessions cannot be shared, the package will not solve the problem on its own.
- Is the clarkewing/handoff guest login flow safe for pre-auth funnels like carts and onboarding?
- The 0.2.0 guest flow extends handoff into pre-auth funnels such as carts, onboarding, and invite acceptance. It mints an authenticated session from an unauthenticated entry point, which is a privilege-elevation surface. Use short TTLs, enforce single use, and bind tokens to the expected domain and audience. Treat the feature as opt-in and review its implementation before enabling it in production.
- How do I prevent open redirects with the continue or return URL in a handoff?
- A guest handoff usually carries a continue or return destination, and unvalidated targets create open-redirect risk. Check whether the package allowlists redirect hosts or passes the value through unchanged. If it passes through, validate against an allowlist of first-party hosts in your own middleware or controller. Never trust a redirect parameter supplied by the browser.
- Is clarkewing/handoff production ready at version 0.x, and how should I pin it in Composer?
- The 0.x versioning means a 0.1.5 to 0.2.0 bump is not a compatibility guarantee, so treat upgrades as potentially breaking. Exact-pin 0.2.0 for new work rather than using a caret, and never float on dev-main for an authentication component. If 0.1.x is already deployed, read the PR #3 diff before upgrading. Single-maintainer maintenance and a low release cadence are additional reasons to review the code before production use.
- Does clarkewing/handoff work with Sanctum, Fortify, Passport, stancl/tenancy, and Laravel Octane?
- The package sits at the authentication and session boundary, so compatibility with Sanctum, Fortify, Passport, or tenancy packages depends on how they share sessions and configure guards. Route caching and Laravel Octane should work if the handoff route is registered normally, but verify Octane does not retain stale config. Multi-tenant packages such as stancl/tenancy need accurate per-tenant domain values in config/handoff.php. Test these combinations in staging before relying on them.
- What are the alternatives to clarkewing/handoff for cross-domain authentication in Laravel?
- If you need full single sign-on, an identity provider or a dedicated OAuth or OIDC solution is a better fit than a lightweight handoff package. For first-party domains that share a session, setting a shared cookie domain with Redis or database sessions may be sufficient without extra packages. clarkewing/handoff targets owned-host handoffs such as marketing to app, tenant subdomains, or legacy migrations. Evaluate whether its signed-URL route mapping saves enough glue code to justify the 0.x risk.