Implement role-based authorization for route access control

[rudokemper]

Feature Request

Currently, when an authentication strategy is set, authenticated users—and only authenticated users—can access all routes in the application. This is not desirable for at least three reasons:

1. The new /config route can be accessed by any authenticated user, when it should be restricted to authorized admin users only, as noted here: https://github.com/ConservationMetrics/guardianconnector-views/issues/70
2. Our users have requested more granular access control. Specifically, they want some views to be accessible to a broader audience while keeping others more restricted. For example, one user wants to allow wide access to the alerts view but restrict access to their Mapeo views.
3. There are times when our users want a certain view to be accessible to non-authenticated users; in other words, a public route.

To accomplish this, we need to add an authorization layer to the app to restrict access to certain routes based on user roles or permissions.

It would be a huge project if we approached this on a granular level, such as determining permissions per view per user. Instead, we could follow a more efficient model similar to what we did in Terrastories, or Superset's standard roles, with a predefined set of roles, such as:

0. Public: technically not a role, but refers to the ability to access a view that does not require any authentication, e.g., logging in.
1. Viewer: can access only unrestricted views routes
2. Member: can access both unrestricted and restricted views routes
3. Admin: can access anything a member can, plus /config

User Story

In the Solomon Islands, our partner organization's alerts methodology is starting to make an impact. They would like to make the alerts view open to a wider audience, including trusted members of other organizations and potentially even members of the government. At the same time, they want to keep other views, showing data from their data warehouse, secure.

Technical notes

• Permissions configuration: Add a config variable permissionLevel and a radio button field to each view on the /config panel, allowing the admin to set the access level.

• API Security: To prevent unauthorized access to API routes, validate access for each endpoint in accordance to Roles.

• Auth0 Integration: Managing roles with Auth0 will require a solution to handle RBAC (c.f. their reference on this). We’ll need to introduce a system where a user's viewsPermission: 1 is set in their Auth0 metadata, similar to the existing approved flag that we use for authentication. Evaluating this will need to happen either in the app or by passing back a query parameter from Auth0. This will require some research on how to integrate this with the Nuxt auth utils that we use.

Timing

This work was scoped for "Replicability 2025-2026." However, if it is deemed strategic to advance our partner’s goals, we may consider starting sooner. In that case, we will need to ensure that we can still meet our other scoped deliverables in the short term.

It would be best to first upgrade this application to Nuxt 3 before proceeding. https://github.com/ConservationMetrics/guardianconnector-views/issues/36

[rudokemper]

If we determine that it is not best to take this work on now, there could be a workaround to meet the short-term needs described in the user story: spinning up a different instance of the application which only has the alerts view set up, and setting up a quick temporary protection for the /config route like making it password protected.