Nuki Laravel Package

Product Decisions This Supports

• Feature viability for multi-tenant smart-lock access: The v1.3.0 security fixes make the package’s sub-user model credible for delegating lock access (e.g., property managers, cleaners, tenants) without leaking account-wide lock state or activity logs. This supports building permissioned dashboards and audit timelines where users only see locks/logs they are explicitly granted.
• Build vs. buy: If your roadmap includes Nuki integration, this release improves the “buy” case by adding package-owned auth middleware, an artisan user-creation command, and role constants. However, the fact that cross-account and sub-user authorization bugs existed until v1.3.0 means a PM should weigh the package’s security maturity and maintenance cadence before committing to customer-facing multi-tenant use.
• Operational onboarding: php artisan nuki:user-create --account=<account_key> simplifies attaching main users to existing accounts as owner, reducing manual setup and support burden for account provisioning.
• UI and auth flexibility: New middleware (AuthenticateNukiUser, RedirectIfNukiUser) and corrected redirect behavior let the package coexist with host-app auth without hijacking host login/dashboard routes. This supports incremental adoption inside an existing Laravel application.
• Feature-scoped rollout: With NUKI_UI_ENABLED=false, profile and sub-user pages no longer 500, and the layout omits missing UI links. This supports headless/API-only or limited-UI deployments.
• Roadmap implication: Prioritize an upgrade to v1.3.0 if you use package users. Audit any custom sub-user management or manual account attachments; the release changes sub-user visibility and redirect behavior, and requires attaching main users to accounts they manage if they were previously relying on the broken cross-account access.

When to Consider This Package

• Consider it when: you are building a Laravel application that needs Nuki smart-lock integration and you want account/lock/sub-user management, activity logs, and a dashboard out of the box. It fits property management, short-term rental access, facilities, or internal ops tools where lock access must be delegated.
• Strong fit if: you use the package’s user model and need sub-user permissions scoped per lock, with audit visibility controlled by view_logs. v1.3.0 makes this safer for real multi-tenant use.
• Proceed with caution if: you need enterprise-grade multi-tenant isolation and cannot tolerate a package that only recently fixed cross-account authorization issues. Require a security review, upgrade path, and regression tests around sub-user permissions before exposing to customers.
• Look elsewhere if: you need vendor-supported SLAs, complex RBAC beyond lock-level permissions, or a package with a long track record of hardened multi-tenant security. Also look elsewhere if you cannot adopt Laravel’s auth stack or need a fully headless API without any package UI assumptions.
• Upgrade note: v1.3.0 is effectively mandatory for existing users with package users enabled. Sub users will see fewer locks/logs by design, guests redirect to /nuki/login, and main users who manage accounts they are not attached to must be attached (syncWithoutDetaching with owner role) or they will lose access.

How to Pitch It (Stakeholders)

• To executives: This release closes serious authorization gaps that could have exposed one customer’s locks and activity logs to another sub user, and it prevents account editors from reaching accounts they do not own. For any customer-facing or multi-tenant deployment, upgrading is a risk-reduction action, not a feature enhancement.
• To engineering: Upgrade to v1.3.0, run regression tests on sub-user lock visibility, activity-log filtering, and account switching, and remove any reliance on the old host-app redirect behavior. Use the new AuthenticateNukiUser middleware for package-guarded routes and the nuki:user-create command for provisioning. If you manually attached users to accounts, no change; otherwise attach main users as owner.
• To product/operations: The package now supports safer delegated access and cleaner onboarding, but it also signals that the integration should be treated as security-sensitive. Budget for permission-model testing and a review of any custom sub-user flows before scaling to external users.