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 What can we do to get this PR through? We are seeing an increased usage of the module and route protection is a common question.

[danielroe]

@DanielRivers I don't believe this PR currently would work on client-side navigation. For example, this code:

const usersPermissions = await nuxt.ssrContext!.event.context.kinde.getPermissions()

will not work in the browser.

[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.