feat: protected routes defined from nuxt config

[DanielRivers]

This adds the ability to protect routes based on permissions of the logged in user

this is all handled by the auth-logged-in middleware

example configuration

    routeRules: [
      {
        "/dashboard": {
		  appMiddleware: ['auth-logged-in'],  // 3.11 or greater
          kinde: {
            permissions: ['example_permission'],
            redirectUrl: "/"
          }
        },
       "/admin/**": {
		  appMiddleware: ['auth-logged-in'], // 3.11 or greater
          kinde: {
            permissions: ['admin_user'],
            redirectUrl: "/"
          }
        }
      }
    ]

This will protect the route protected to only users with the permission of example_permission and all routes under admin need to have admin_user permission

An array of permissions can be defined, along with an optional redirectUrl. If not redirectUrl is supplied the user will be presented with a 401 error as per the current behaviour.

For versions 3.10 and lower you have to define the middleware on the you want to be protected

definePageMeta({
  middleware: ['auth-logged-in'],
})

This is a built in solution for #45

[danielroe]

What about using custom routeRules for this?

[DanielRivers]

@danielroe I can't see what I have done to break the virtual file src/runtime/server/utils/client.ts

None of my seem to marry up to cause the error.

[danielroe]

One question is whether we instead move forward with nuxt/nuxt#25841 rather than implementing this specifically in this module. That would allow kinde middleware to be applied in a more generic way. Do you see any limitations in that PR?

[DanielRivers]

One question is whether we instead move forward with nuxt/nuxt#25841 rather than implementing this specifically in this module. That would allow kinde middleware to be applied in a more generic way. Do you see any limitations in that PR?

@danielroe That looks good, I was hoping to find a way to trigger the middleware without having to add middleware: ['auth-logged-in'] to every page.

one would assume that the rest of the route payload would be accessible so can continue to use the following style of config and extend as needed?

    "/protected": {
      kinde: {
        permissions: ['example_permission'],
        redirectUrl: '/',
      }
    },

I can pull the PR and have a look in more detail, but if I understand right not a huge amount would change just really how its triggered?

[DanielRivers]

@danielroe What changes are needed to get this over the line?

[danielroe]

Iterated on this a little bit - hope it still looks good to you.

My main concern right now is that this only works on server-side. Is that intended? If so we should add some handling in the middleware for client/server.

[DanielRivers]

@danielroe Mostly your changes looked good, I had to change slightly the implementation of getRouteRules as it crashed when accessing any protected route.

I have tested on both direct access and using NuxtLink.

[DanielRivers]

@danielroe I have implemented client support, added an access endpoint which checks if the logged in user has access to the route, returns the returnUrl and access boolean.

[DanielRivers]

@danielroe little nudge on a review 🙏

[DanielRivers]

@danielroe Can this get a review please?

[danielroe]

I feel this should be done entirely on the client side rather than requiring an extra request every time someone tries to navigate to a given route.

are the permissions exposed/accessible to the client?

[DanielRivers]

They're currently not as they are only on the token, I can certainly fetch and store in memory store on client when attempting to use and not there yet.

[danielroe]

FWIW, I think it would make sense to use a /_kinde prefix or something for e.g. /_kinde/access ... as these are quite generic and could easily overlap with user endpoints.

[danielroe]

can users access pages while being logged out? if not, this should be moved earlier to L18 so we don't need to perform a network request or get the route rules

[danielroe]

user-defined route rules are only available on the server - so this will not provide any protection on the client

(so this can be moved after the import.meta.client block)

[danielroe]

we want to use a route rules matcher here as they are nested, so a parent matcher can set permissions on a child route, e.g.:

/**: {
  kinde: {
    permissions: ['example_permission'],
  }
}

(this would apply to all routes but wouldn't be detected by this code.)