- Does nette/security work with Laravel out of the box?
- No. nette/security is a Nette Framework component: its wiring lives in the Nette DI SecurityExtension, its session persistence depends on nette/http, and its UserPanel helper targets the Tracy debug bar. None of that maps onto Laravel's container, middleware pipeline, or session guards. There is no native Laravel adapter and no community bridge on record, so every integration decision is bespoke.
- How do I install nette/security in a Laravel project?
- You can pull it in with composer require nette/security, and it installs as a plain PHP library without a Laravel service provider or package auto-discovery. Using it meaningfully means registering its services manually and writing adapters, notably a Nette UserStorage backed by Laravel's session and a mapping between IIdentity and Illuminate Authenticatable. Budget for custom integration code rather than a drop-in install.
- Which Laravel and PHP versions does nette/security support?
- The library targets modern PHP, including PHP 8.5, with PHPStan enforced in CI. It declares no Laravel version support because it is not a Laravel package; its compatibility surface is Nette Framework components, not Illuminate. In practice, Laravel version support is whatever your bridge layer supports, and that compatibility is yours to maintain.
- Can I use nette/security's ACL Authorizator with Laravel gates and policies?
- Technically yes: wrap the Authorizator as a Laravel service and consult it from gates or middleware. The architectural problem is deciding which engine is the system of record for permissions, because two permission engines create debugging and compliance hazards. Pick one owner and keep the other as a thin adapter, or you will eventually ship checks that disagree.
- How do I bridge Nette's UserStorage with Laravel's session and Auth guard?
- Implement Nette\Security\UserStorage on top of Laravel's session and Auth guard, then map IIdentity to and from Illuminate\Contracts\Auth\Authenticatable so Blade @auth, Gate::allows, and policy discovery do not fork into two truths. The hard part is reconciling semantics: logout, sliding expiration, expire_on_close, guest roles, and cache invalidation. User::refreshStorage() exists precisely because identity caching causes stale reads.
- How does nette/security handle password hashing compared with Laravel's Hash facade?
- Nette Security's Passwords object supports bcrypt and argon2, broadly the same algorithms Laravel's Hash facade offers. The risk is that the two carry separate hasher configuration and rehash-on-verify policies, so mixing them creates inconsistent upgrade paths. Choose one hashing owner and confirm existing hashes can be rehashed during login.
- Is nette/security a replacement for spatie/laravel-permission or Laravel's native auth?
- No. Laravel already provides authentication, gates and policies, session guards, and CSRF protection, while spatie/laravel-permission covers role-based ACL with first-class Laravel integration. nette/security reimplements those concepts for Nette and has no Laravel adapters, community bridge, or Stack Overflow corpus. Adopt it only as a deliberate vendor-neutral ACL layer across frameworks, not as a Laravel auth solution.
- What are the production risks of running nette/security and Laravel auth side by side?
- Expect two sources of truth: divergent Auth::user() results, stale identity caches, and permission checks that disagree. That is a security-review blocker, not a code-hygiene nit. There is also a maintenance risk, since upstream fixes target nette/http compatibility rather than Laravel sessions, so Laravel-specific breakage is yours to fix.
- Is nette/security actively maintained, and what is its license?
- Yes, it is maintained: releases are current, PHP 8.5 is supported, PHPStan runs in CI, and v3.1.0 already paid down the I*-prefix debt. The catch is that license metadata shows NOASSERTION, so legal must verify the actual license, BSD-3-Clause in practice, before enterprise adoption. Major versions have carried BC breaks in v3.0.1, v3.1.0, and v3.2.0, so pin versions in your bridge layer.
- How should I test a nette/security integration before shipping it?
- Budget three to five engineer-weeks for a production-grade spike rather than a three-day proof of concept. Start by proving session-expiry semantics against Laravel's session middleware, since that is the package's main differentiated behaviour and the focus of the v3.2.3 and v3.2.4 fixes. Then test logout, guest roles, cache invalidation, and permission parity between both stacks before releasing.