Edit:

Currently, an icon is only displayed in the submenu if it is a NAV_ITEM_TYPE_COLLAPSE. This is not the case with “NAV_ITEM_TYPE_ITEM.”

All right. Never mind. I found it after all. I was able to change it by modifying the cascade. Thanks anyway. Keep up the good work!

Great to heard that, please let us know if you have any further question.

Hi again,

Is the TypeScript error in middleware.ts already known? It occurs as soon as you follow the documentation and enable role-based access.

[{ “resource”: ”/C:sample/src/middleware.ts”, “owner”: “typescript”, “code”: “2339”, “severity”: 8, “message”: “Property ‘authority’ does not exist on type ‘User’.”, “source”: “ts”, “startLineNumber”: 57, “startColumn”: 82, “endLineNumber”: 57, “endColumn”: 91, “origin”: “extHost1” }]

Should authority be part of the authenticated user object by default, or is the authentication setup incomplete?

Best regards, Mason

Hi, thanks for pointing this out! This is indeed one of the slightly inconvenient parts of extending the default NextAuth session types.

Here’s what you can do: create a next-auth.d.ts file under src/@types and add the following type declarations:

import 'next-auth'

declare module 'next-auth' {
  interface Session {
    user?: {
      id: string | null
      name: string | null
      email: string | null
      image: string | null
      authority: string[]
    }
  }
}

declare module 'next-auth/jwt' {
  interface JWT {
    sub?: string
    authority?: string[]
  }
}

This should resolve the type errors related to session and JWT extensions. We’ll also include this information in our documentation in the next update to make it clearer for everyone.

Thanks, the idea of following the official documentation sounds reasonable.

However, I’ve just noticed that a huge amount of adjustments are needed to make the entire authority system work properly.

Currently, at the point where you add the next-auth.d.ts, the permission checks don’t work.

Users can access pages marked as “authority: [ADMIN]” even if they only have “authority: [‘user’]”.

Hi, we tested the interceptor in the middleware, and it correctly redirected to the “Access Denied” page with the following scenario:

- Page authority: [‘admin’] - User authority: [‘user’]

It shouldn’t require much adjustment to get it working. Please share your implementation with us via our support page https://themeforest.net/item/ecme-the-ultimate-react-tailwind-admin-template/54470284/support, and we can discuss further over email.

Hello, I think this belongs in this section.

callbacks: { async session(payload) { /** apply extra user attributes here, for example, we add ‘authority’ & ‘id’ in this section */ return { ...payload.session, user: { ...payload.session.user, id: payload.token.sub, authority: [‘admin’], }, } }, },

The authority uses the static value (auth.config.ts) from it, right? The value within the mock (authData) is not used, right?

And sorry for asking such unnecessary questions.

No problem! After looking into it further, we realized that our NextAuth configuration was missing a few parts. Since the template doesn’t enforce permission settings by default, we hadn’t fully implemented the logic for passing extra fields to the token.

Here’s the complete callback configuration in auth.config:

providers: [
    ...
    Credentials({
        async authorize(credentials) {
            /** Validate credentials from backend here */
            const user = await validateCredential(
                credentials as SignInCredential,
            )
            if (!user) {
                return null
            }
            console.log('user', user)
            return {
                id: user.id,
                name: user.userName,
                email: user.email,
                image: user.avatar,
                authority: user.authority,
            }
        },
    }),
],

callbacks: {
    async jwt({ token, user }) {
        // Persist the authority to the token right after signin
        if (user) {
            token.authority = user.authority
        }
        return token
    },
    async session({ session, token }) {
        // Send properties to the client
        return {
            ...session,
            user: {
                ...session.user,
                id: token.sub,
                authority: token.authority,
            },
        }
    },
}

This setup should correctly inject the authority field into the token, allowing the middleware to access it properly.

Also, make sure to include this check in the middleware to prevent API requests from being intercepted:

!nextUrl.pathname.startsWith(appConfig.apiPrefix)

if (isSignedIn && nextUrl.pathname !== '/access-denied' && !nextUrl.pathname.startsWith(appConfig.apiPrefix)) {

We’ll include this fix and update our documentation in the next release to help prevent any future confusion. Thanks again for bringing this issue to our attention.

Sounds good. I also don’t want to ask unnecessary questions, but in this case it was the right thing to do.

One important thing remains, does the typing stay like this?

@types/next-auth.d.ts:

Because right now there’s still a small error:

“Property ‘authority’ does not exist on type ‘User | AdapterUser’. Property ‘authority’ does not exist on type ‘User’.ts(2339)”

This occurs at user.authority in auth.config.ts inside the async jwt callback.

No worries at all! You’ll still need the next-auth.d.ts file, and it should look like this:

import { DefaultSession, DefaultUser } from 'next-auth'
import { DefaultJWT } from 'next-auth/jwt'

declare module 'next-auth' {
    interface Session {
        user: {
            id: string
            authority: string[]
        } & DefaultSession['user']
    }

    interface User extends DefaultUser {
        authority: string[]
    }
}

declare module 'next-auth/jwt' {
    interface JWT extends DefaultJWT {
        authority: string[]
    }
}

Ahh, that makes sense. But now you can’t output more data from the session with just “user,” can you? For example, “{session?.user?.name || ‘Anonymous’}”.

Yes, you can. You can manipulate the returning from session

user: {
    ...session.user,
    name: session?.user?.name || 'Anonymous',
    id: token.sub,
    authority: token.authority,
},

Sorry, that question was poorly phrased.

Here’s some context: after changing next-auth.d.ts, there are type errors all over the script.

For instance: “Property ‘name’ does not exist on type ‘(User & Record<string, any>) | {}’. Property ‘name’ does not exist on type ‘{}’.”

This error appears in the standard output of “{session?.user?.name || ‘Anonymous’}.

Btw I’m really surprised by the quick responses. Respect, keep up the good work!

Thanks, now we understand where your question coming from, since we re-declared the next-auth type in next-auth.d.ts, so we need to make some changes on type that we explicit in SessionContext.tsx & useCurrentSession.ts

here’s the new SessionContext.tsx & useCurrentSession.ts code

'use client'

import { createContext } from 'react'
import type { Session } from 'next-auth'

const SessionContext = createContext<Session | null>(null)

export default SessionContext

import { useContext } from 'react'
import SessionContext from '@/components/auth/AuthProvider/SessionContext'

const useCurrentSession = () => {
    const context = useContext(SessionContext)

    return {
        session: context,
    }
}

export default useCurrentSession

This should fix the type error. Thanks again for bringing this to our attention — it really helps us see where we still have room to improve.

Very clever! It makes sense. I have one last question on this topic. Would it be possible to modify the sidebar within the script, with minor changes, so that only the items you have authority over are rendered? Also, is this already built in?

Hi, the authority check is included in the SideNav, but embarrassingly, there was a small typo on line 98 of SideNav.tsx. Once corrected, it’ll work as expected. We’ll also include all these fixes in our next update.

Ahhh, unfortunately I didn’t find the mistake myself, but I noticed that the structure is definitely there. Always these little typos. Thank you very much! Have a nice day & thanks for your help. <3

No problem!, reach out any time if you encounter any issues.

Hey, I’m back for once. It’s not about a bug or anything, but could you maybe give me an example of how you use the notification, for example, based on the login? If not, that’s fine, then it will have to find out somehow. Thank you

Hi, no worries — you can either use the Toast component (https://ecme-next.themenate.net/ui-components/toast ), or combine the useTimeoutMessage hook with the Alert component to create a feedback message similar to the login page.

Here are the references:
- useTimeoutMessage: https://ecme-next.themenate.net/guide/utils-doc/use-time-out-message
- Alert: https://ecme-next.themenate.net/ui-components/alert

Hey! I forgot the thank you. I just wanted to quickly mention something I noticed about the authority logic. After making changes, the authority check now triggers before the 404 handling. For example, if a user enters a non-existent URL such as https://example.com/the-site-does-not-exist, the “Access Denied” page is displayed instead of the “Page Not Found” message.

Do you have any idea what could be causing this? This has been happening ever since we made the site role-based.

Hi, was about to mention this, we need to add an additional check alongside the includedRole before it redirects to the “Access Denied” page. Here’s what the complete code should look like:

if (isSignedIn && nextUrl.pathname !== '/access-denied' && !nextUrl.pathname.startsWith(appConfig.apiPrefix)) {
        const routeMeta = protectedRoutes[nextUrl.pathname]
        const existingRoute = routeMeta
        const includedRole = routeMeta?.authority.some((role) => ['user'].includes(role))
        if (existingRoute && !includedRole) {
            return Response.redirect(
                new URL('/access-denied', nextUrl),
            )
        }
    }

The ‘user’ is then hardcoded and cannot be ‘user’ or ‘admin’. This means that an ‘admin’ can no longer access any page, right?

Sorry, its our mistake, here’s the correct version

if (isSignedIn && nextUrl.pathname !== '/access-denied' && !nextUrl.pathname.startsWith(appConfig.apiPrefix)) {
        const routeMeta = protectedRoutes[nextUrl.pathname]
        const existingRoute = routeMeta
        const includedRole = routeMeta?.authority.some((role) => req.auth?.user?.authority.includes(role))
        if (existingRoute && !includedRole) {
            return Response.redirect(
                new URL('/access-denied', nextUrl),
            )
        }
    }

Ahh very nice. Thank you

No problem!

Sup, quick report: Inside @types/auth.ts, there’s a small typo in the token type.

Hi, thanks for reaching out! Does this error occur on one of the existing pages or a custom page you’ve built? Please feel free to send us a message through our support mail: https://themeforest.net/item/ecme-nextjs-tailwind-admin-template-app-router/56475600/support — we’ll be happy to take a closer look and help you resolve it.

No i just npm install, npm run dev. Console Error

Hydration failed because the server rendered HTML didn’t match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used

Hi, we just tested it on our end and didn’t encounter any hydration error. would you mind to try again in incognito mode, or a browser without any extension installed? If you’re still seeing this issue, could you share more details about your setup or screenshot via our support mail?

Can I send you the picture? Can I have your email address?

Hi, in the demo, there’s no role restriction for all the pages. However, we’ve already implemented role-based functionality in the source code for anyone who needs to enable it.

I tried changing the authority for some routers. Example with the router ”/concepts/projects/project-list” has authority: “marketing”, User has authority: “admin”, but still can access

Hi, it might need to tweak the middleware a bit for the route intercept. Please send us a support email, and we’ll guide you through implementing the role check intercept.

No problem! please send us along with your purchase ID.

Sure

What your email address I can send my purchase ID?