Modify the order of beforeEach guards

[LukMas]

Hi!

I would like to know if there is the possibility to modify the order of which the beforeEach guards are called. I know that they are called following their creation time, but I've the following problem:

1. first the user creates the router, defines all the routes and set ups some beforeEach guards
2. then the user creates our authentication plugin, and this requires the router to work correctly

The problem is that with this configuration the workflow is not producing the desired results. Under some circumstances the final result is not the expected one, and the reason is the order of the beforeEach guards. Indeed, moving our custom beforeEach guards after the one created in the authentication plugin produces the correct effect.

Hence, is there a way to modify the order of this guards? If not, is there a way to define the priority of them?

[Deckluhm]

What about declaring your authentication guard first but ignoring it until the user is authenticated?

Something like that:

router.beforeEach((to, from) => {
  if (isAuthenticated) {
    // Do something
  }
  return true
})

Here isAuthenticated could be something coming from your store (or anywhere you store the authentication status).

[LukMas]

Thank you for your help. The things not exactly so simple, that's why this solution would not work. In detail the authentication guard works like this: 1. User tries to access a protected route 2. The router sees that the user if not authenticated (trying to obtain his information and getting a 401 error) and automatically sends him to the login screen (we still have to use a CAS authentication system) 3. After the authentication the CAS and then the application backend return to the frontend to a special page (/home) 4. The router checks again the user, finds its information and allows the route (returning true) Then, normally, any custom guard that kicks in for a protected route (we sign them with special meta attributes - better, the /home carries this meta information, while the other routes are its children and get it automatically) would normally work like this: 1.if that route comes, it means that the authentication was successful (because the authentication guard allowed it) 2. According to the content of the user information a different route, or just true, is returned 3. Any other situation (user information empty) should return false because the route is protected In our situation, given that the custom guard comes before the authentication one, we have to do the things in a different way. We still control the meta of the route and check for the user information. But, instead of returning false if its empty, we must return true to allow the next guard (the authentication one) to kick in and complete the authentication process. Thus because the first and foremost route that this guard sees is the /home one, that's exactly the one that is returned upon a successful authentication. I know that I could configure a per route guard. I've also tried and it works. But I've to duplicate some logic (of perform some extra work) for every sub route of the /home. And the whole 'routing rules' are scattered in every sub route. With a more generic code this would be simpler to understand and much concise. Unfortunately I've not found a better solution than forcing to add any custom guard after the authentication one.

…

On Thu, 4 Jul 2024, 16:08 Arnaud Thomas D., ***@***.***> wrote: What about declaring your authentication guard first but ignoring it until the user is authenticated? Something like that: router.beforeEach((to, from) => { if (isAuthenticated) { // Do something } return true}) isAuthenticated could be something coming from your store or something like that. — Reply to this email directly, view it on GitHub <#2292 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXPQCE2WU3CMIXVQ54ATY3ZKVJNDAVCNFSM6AAAAABKLIXDH2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNJZGU4TC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Deckluhm]

Won't lie, it's a bit hard to understand how everything works in your application without the actual code.

Is the plugin you are talking about an external package you have no control over?

[LukMas]

Router definition:

const router = build_router(
    createWebHistory(import.meta.env.BASE_URL),
    [
        {
            path: '/',
            component: LayoutView,
            children: [
                {
                    path: "/colors2",
                    component: ColorsView,
                    meta: {
                        breadcrumb: {level1: 'Styleguide', label: 'Colors'}
                    }
                }
            ]
        },
        {
            path: '/home',
            component: LayoutView,
            meta: {
                requiresAuth: true
            },
            children: [
                {
                    path: "/colors",
                    name: "DashboardStudent",
                    component: ColorsView,
                    meta: {
                        requiresRole: 'STUDENT',
                        breadcrumb: {level1: 'Styleguide', label: 'Colors'}
                    }
                },
                {
                    path: "/button",
                    name: "DashboardAdmin",
                    component: ButtonView,
                    meta: {
                        requiresRole: 'ADMIN',
                        breadcrumb: {level1: 'Button', label: 'Button'}
                    }
                },
                {
                    path: "/avatar",
                    name: "avatar1",
                    component: AvatarView,
                    meta: {
                        breadcrumb: {level1: 'Misc', label: 'Avatar'}
                    }

                },
                {
                    path: "/avatars/:avatarId",
                    name: "avatar2",
                    component: AvatarView,
                    meta: {
                        breadcrumb: {level1: 'Misc', label: 'Avatar'}
                    }

                },
                {
                    path: "/avatars/:avatarId/minions/:minionId",
                    name: "AvatarsAndMinions",
                    component: AvatarView,
                    meta: {
                        breadcrumb: {level1: 'Misc', label: 'Avatar'}
                 }
            ]
        }
    ]
);

export default router;

Authentication guard. The this.fetchUserDetails() automatically redirects to the login if the response is 401, hence no other code path would be required.

private async authenticateRoute(to: RouteLocationNormalized) {
        if (to.meta.requiresAuth) {
            this.logMessage(`Checking the login status for the route ${to.fullPath} . `);
            // identify to which concrete route the user wants to go
            // the last one in the list is always the most fitting route that the router has found, hence the one
            // where the user wants to go
            let concreteRoute = to.matched.slice(-1)[0];

            if (concreteRoute === undefined) {
                throw Error(`In the matched routes no concrete route with path ${to.path} exists.`);
            }

            // if the route is a protected route but not the login callback...
            if (!concreteRoute.meta.requiresAuth) {
                this.logMessage(`Not login callback, save the route ${concreteRoute.path}`);
                // ... backup the destination route, we need to know where the user wants to go
                this.cacheRoute(to.fullPath);
            }

            // check if the user is authenticated trying to obtain his details
            await this.fetchUserDetails().then(async () => {
                const cachedRoute = this.uncacheRoute();
                if (cachedRoute !== null) {
                    this.logMessage(`Restore saved route ${cachedRoute}`);

                    return {fullPath: cachedRoute};
                }

                this.logMessage(`No cached route, allow original route ${to.path}`);
                return true;
            });
        }

        // allow the route, if defined other guards will kick in
        return true;
    }

Custom extra guards:

export function addDashboardRedirect(router: Router) {
    router.beforeEach(async (to) => {
        if (to.meta.requiresAuth) {
            const {userDetails} = useAuthenticationService();
            console.log("userdetails: " + JSON.stringify(userDetails.value));
            if (to.path === '/home') {
                if (userDetails.value.roles.includes('ROLE_ADMIN')) {
                    return {name: 'DashboardAdmin'};
                } else {
                    return {name: 'DashboardStudent'};
                }
            }
            if (to.meta.requiresRole === 'STUDENT' && !userDetails.value.roles.includes('ROLE_STUDENT')) {
                return {name: 'DashboardAdmin'};
            }

            // Student tries to access some admin related stuff -> redirect to student dashboard
            if (to.meta.requiresRole === 'ADMIN' && !userDetails.value.roles.includes('ROLE_ADMIN')) {
                return {name: 'DashboardStudent'};
            }
        }

        return true;
    });
}

If I define the authentication guard before, everything works as expected. I would redirect to the correct dashboard after the login. Moreover, I know that at this stage any route with meta 'requiresAuth' has for sure access to the user, because the guard before guarantees that if no user is set a login is done.
On the other side, if the guards are inverted, there is not way to go to the correct route because the custom guard kicks in before the authentication one. Hence I would lose my final destination, because the whole routing logic is lost. Moreover, I've also to actively check for the existence of the user, because I can't be sure that is already set (the 1. run, just after the login, is still not set).

[LukMas]

I know that I could set the beforeEach in every route, and this solves the problem. But this is a stripped down version of the whole code. I should repeat some logic in several routes. Or group them in another lever (admin and student).

It could be a solution, that is true.

But, everything comes because there is no way to define the priority of the guards.

[Deckluhm]

There is currently no way to define guards priority other than changing the order in which you declare your guards.

If you can't find a way to reorganize your code, maybe you can try to use beforeEach return value which is a method to unregister the guard. That way you can kind of control the registration order of your guards (by removing and adding them again).

But I truly suggest to see how you can adapt your code to declare guards in the correct order so you don't have to do that.

[LukMas]

Yes, I've seen.

I've thought about this, but I find it a somewhat convoluted solution. Given that we could do it, it's better to adapt the code in a way that it works as it should without modifying the order of the guards.

Anyway, I also think that while we could do it, not always is this possible. Then, maybe having this as future feature would be a nice add on. In my eyes there should exists guards that take the priority over others, and should kick in before regarding the order they have been defined.

Thank you for your help!

[posva]

FYI, @Deckluhm proposal is the correct way to ensure the guards are in the correct order. e.g. tell your plugin users to add the plugin before other guards and before installing the router plugin (that starts the initial navigation):

const router = createRouter(...)

YourPlugin(router)

// user guards

router.beforeEach()


app.use(router)

[LukMas]

Yes, I agree.
Given that the plugin handles the first and foremost routing guard, it should come before every other custom guard that the user could set up.
Moreover, checking better the code and the routing logic, if the custom general guards (beforeEach) are split and set up within the routes definitions would become simpler and faster to understand for who see the code later on.