Please (re)consider separate Nova policies

[jerrebm]

I am aware that this issue has been brought up before (#131) but was then discussed in the context of multi-tenant applications. I'd like to propose another perspective as to why I believe it is worth considering defaulting to policy separation between the app and Nova:

I appreciate that every project has different "expectations" of what an admin panel is supposed to do, but I'd argue that the following most commonly applies to user-facing Laravel projects:

1. Given that Nova is an admin panel, only users associated with the organization building the app (IE developers) should have access. Regular users should never have access.
2. Within the organization that builds the app, more granular authorization of Nova requests may be required (IE, perhaps only administrators may delete records).

For example, consider a medium-sized SaaS application:

1. A regular user may be assigned different roles/permissions within their team. Policies are used to authorize actions associated with those roles and permissions.
2. The organization building the app may require authorization of Nova requests based on job titles (IE Developer vs. Support agent vs. sales rep).

When reading through Nova's documentation, the proposed solution is to utilize Nova's whenServing method within each policy check, to separate authorization logic between Nova and non-Nova requests.

The problem with this approach is that it will quickly become very messy in the provided context. Essentially every single policy check throughout the application requires different logic for regular vs. Nova users.

An alternative approach might be to leverage the authorizedToView, authorizedToDelete, etc. methods on Nova resource classes, but this is less intuitive and centralized and therefore more prone to mistakes. If a developer isn't aware or forgets that this is how authorization for Nova requests is handled, Nova will default to the incorrect policies.

A better workaround is probably to override policies in the NovaServiceProvider (as shown in this comment)

But I'd argue Nova should separate these policies out of the box since this is the most sensible default for most applications (almost any SaaS app when the business scales beyond a certain size). It also doesn't downgrade the experience for projects who do have a lot of overlap in policy logic. After all, the Nova policy can simply extend the regular policy and only overwrite checks where necessary. Or alternatively, Nova may default to the regular policy if no Nova-specific policy exists for the given resource.

[kusab85]

@jerrebm, good points!

Nova may default to the regular policy if no Nova-specific policy exists for the given resource.

IMHO worth implementing.

I am currently doing advanced acrobatics to separate Nova and non-Nova authorization logic :-/

[bkuhl]

I also find myself spending less time writing an action than it takes to figure out the permissions around why I can't run the destructive action. I'd welcome simplification around these permissions.

[pedro-santiago]

We had the same problem here, and managed to separate it. We have the following structure:

• NovaCoreProvider (Boots the entire application)
• NovaPoliciesProvider (Boots only policies, and they are only loaded within Nova).
• NovaMenuProvider (... )

We created a namespace for Nova Policies and extended the default policy so they only load inside nova.

[crynobone]

Available in Laravel Nova 5: https://nova.laravel.com/docs/v5/resources/authorization#using-separate-policy-classes-for-nova-resources