Nuki Laravel Package

Technical Evaluation

• Architecture fit: The package is a Laravel-native Nuki smart-lock integration with package routes, middleware, Blade UI, artisan commands, and an account/sub-user permission model. v1.3.0 improves fit for host applications by moving guest/auth redirects into package-owned middleware (AuthenticateNukiUser, RedirectIfNukiUser) rather than relying on host login/dashboard routes.
• Integration feasibility: Straightforward for a Laravel app that can adopt package auth and UI conventions. The release is primarily a security and authorization hardening release. Most fixes are described as “nothing to do,” but existing installs need validation around account attachment, published views, and custom route/auth overrides.
• Technical risk: High security sensitivity. The release closes serious authorization gaps: sub-user visibility across locks/activity logs, cross-account sub-user editor access, and permission-row overwrites by ID. Any custom forks, overridden views, custom sub-user endpoints, or copied package code may retain the old vulnerable behavior. The changed sub-user visibility is intentional but may be perceived as a regression by users who expected account-wide visibility.
• Key questions:
  • Which Laravel/PHP versions are supported, and are migrations required for v1.3.0?
  • Are account and lock permissions centralized in policies/Gates, or enforced only in controllers/views?
  • Are there extension points/events for account attachment and permission changes?
  • How should existing accounts be backfilled when package users are enabled but attachments were created outside the package?
  • Is NUKI_UI_ENABLED=false a supported API-only/headless mode?
  • What regression tests exist for guest, main-user, sub-user, cross-account, and UI-disabled scenarios?
  • Does nuki:user-create behave idempotently, and how does it report partial failures?
  • What is the audit path for prior exposure to cross-account logs, locks, and sub-user edits?

Integration Approach

• Stack fit: Fits Laravel applications using Blade, Laravel auth, artisan, and package-provided UI routes. Teams can place their own routes behind Darvis\Nuki\Http\Middleware\AuthenticateNukiUser and use NukiAccount::ROLE_OWNER / ROLE_MEMBER for role checks.
• Migration path:
  1. Pin v1.3.0 and review all customizations, published views, route overrides, and middleware.
  2. Upgrade in staging with both package users enabled and disabled.
  3. For existing accounts with package users, attach main users explicitly if they were not attached by hand: $user->accounts()->syncWithoutDetaching([$account->id => ['role' => 'owner']]).
  4. Use php artisan nuki:user-create --account=<account_key> for new main users where applicable.
  5. If the redirectGuestsTo() closure from the 1.2.1 documentation was added, it can be removed, though leaving it is harmless.
  6. If views were published, diff layouts/app.blade.php against the package version, especially UI links, account switcher, and brand link behavior.
• Compatibility: No breaking API change is called out, but behavioral changes matter: guests now land on /nuki/login; signed-in package users are redirected to auth_users.redirect_after_login; sub users see only permitted locks and log entries. Installations without package users are unchanged. Host applications that relied on package pages redirecting to host login/dashboard must update tests and runbooks.
• Sequencing: Inventory custom auth/UI code first; upgrade staging; run authorization regression tests; backfill account attachments; validate UI-enabled and UI-disabled modes; then deploy with monitoring. After deployment, communicate the reduced sub-user visibility as a security correction, not a feature regression.

Operational Impact

• Maintenance: Moderate. The package is security-sensitive and should be kept current. Custom views and custom sub-user/account management code require ongoing review because they can bypass the package’s authorization fixes.
• Support: Expect possible tickets from sub users who no longer see all locks or account-wide activity logs. Support should explain permission-based visibility and how to grant view_logs or lock permissions. Missing-account reports may indicate unattached main users, especially for accounts created under 1.2.0.
• Scaling: No major scaling concern is evident from the release notes, but permission-filtered dashboard/activity queries should be indexed and load-tested for accounts with many locks/users. The CLI user-creation command helps onboarding scale operationally.
• Failure modes: Unauthorized activity filters should return 403 by design. Existing accounts may appear unreachable if not attached. Published layouts may still reference nuki.dashboard when NUKI_UI_ENABLED=false, causing errors. Mixed host/package auth middleware can create redirect loops or unexpected login destinations. Custom endpoints may still expose cross-account data if they do not use the new middleware and permission checks.
• Ramp-up: Low for Laravel developers familiar with packages, middleware, and Blade. Moderate for support/admin teams because the account/sub-user permission model and security semantics need clear documentation. A short security-focused code review is warranted for any customized installation.