Next-auth: Question: proper way to configure vercel.json routes for dynamic path segments

[emmenko]

Hi, I have a question about configuring the routes in vercel.json to correctly point to the dynamic route [...slug].js.

This is not really related to the next-auth library, but given it uses a dynamic path I thought to ask the question here first.

The background is that I'm trying out the Multi zone setup, which requires some route mapping in vercel.json.

I managed to somehow make it work by doing this:

{
  "src": "/api/auth/(.*)",
  "dest": "accounts/api/auth/[...slug]?params=$1"
}

The accounts is the name of one of the website folders.

// /api/auth/[...slug].js

export default (req, res) => {
  const { params, ...rest } = req.query;
  // On production, routes are configured in `vercel.json`.
  // For dynamic routes like this `[...slug]`, we pass the route paths
  // as a `params` query parameter.
  // Therefore, the keep the original functionality, we need to patch the
  // query parameters to use `slug`, which is a list of paths.
  if (params) {
    req.query = {
      ...rest,
      slug: params.split("/"),
    };
  }
  return NextAuth(req, res, options);
};

I'm wondering if there is a better way to do that. Thanks 🤗

[iaincollins]

Oh! That's really interesting. Thanks for sharing your config!

I am not sure, but I think this is an interesting question, and there might be scope for providing an easier way to do this in (e.g. by exporting a route handler like next-auth/route).

I've been wondering about adding the option to have NextAuth() route handler look for nextauth.config.js file in the root directory if the 'options' argument is blank; that might work well in this scenario.

Without actually trying it out, it's not clear to me just from scanning the docs for multizone to know if that is possible, but if there are any examples of how to use a module endpoint as a route that would be super helpful.

[emmenko]

Yeah I've been digging the docs and trying things out in the past hour and this was the only way I was able to make it work.

Another interesting question (out of curiosity) is about prefixing the API routes, especially the ones from next-auth.

For example, instead of /api/auth/signin, the routes could be served as /accounts/api/auth/signin

I see that there is an option to pass a basePath:
https://github.com/iaincollins/next-auth/blob/f53a7f3b85f673627514b87430785c2e9bb7ae7e/src/server/index.js#L41

I'm not sure this is the right option though, for example also the site url should be adjusted I suppose.

[iaincollins]

Hey I totally forgot to document that option, thanks for reminding me!

Yeah that would absolutely be the right option.

e.g. basePath: '/account' would give you routes like this:

/account/signin
/account/callback
/account/callback/google
/account/callback/facebook (etc)
/account/signout
/account/errror

Currently, the only caveat for this is that the client needs to know about a basePath if it's called.

e.g.

• session({ basePath: '/account' })
• useSession(null, { basePath: '/account' })

This is not documented as, well, it's not very nice and I wanted to make it better.

One option would be to support checking an environment variable like NEXTAUTH_BASE_URL which people could set and configure to export to the client.

However, I'm not clear technically on the best way to do this, and I see that it's in flux in Next.js a little bit - with new .env handling in Next.js in active development so maybe it's worth ignoring for now.

I'm not sure this is the right option though, for example also the site url should be adjusted I suppose.

Oh you are right, basePath is the best option! The site option actually needs to be the top level URL, which the documentation doesn't really specify. It's used to automatically set a policy for callback URLs, etc to prevent bad actors from trying to do naughty things. I just realised the advance option for customising that behaviour isn't documented yet either.

I think the custom pages option is probably the best route in the short term here, rather than customising the basePath. Creating custom sign and signout pages is a bit of a hassle right now, but stuff will come later this week to make that easier.

[emmenko]

Thanks for the detailed explanation.

I guess having this behavior documented would be more than enough for starters. Then you can look at a more permanent and nicer solution.

For instance, I would expect this option to work similarly like Gatsby’s pathPrefix which you set in the gatsby-config.js.
Then Gatsby (or NextAuth in this case) can take care of adjusting the paths and links internally, in production mode.

[iaincollins]

I think the features and documentation for this has improved - and basePath should work in both client and server - so closing this one off.