Link to a protected page fails when using i18n routes with next 11.1.0

[vitormv]

Describe the problem

When using the latest Next.js v11.1.0, and having i18n routes enabled, any <Link /> that points to a protected page will fail. In Next.js 11.1, they removed the locale prefix from api routes, but it seems Auth0 package is still trying to redirect to a locale prefixed route.

I tried setting up "NEXT_PUBLIC_AUTH0_LOGIN="/api/auth/login"" in the .env file. Also tried to manually set the login route in the , but the issue persists

What was the expected behavior?

User should be redirected to /api/auth/login instead of /en/api/auth/login.

Reproduction

I created a sample codebox where you can see the issue. Clicking on the regular <a> link works fine (ignore the error page on the Auth0 side). But trying to reach the same package when using a <Link /> leads to a redirect to api route with a prefix.

https://codesandbox.io/s/peaceful-smoke-0iubu

Of course, the external Auth0 login page will show an error since there are no correct Auth0 for a real project, but just reaching the page can be considered a "success" in this case.

Environment

    "@auth0/nextjs-auth0": "1.5.0",
    "next": "11.1.0",
    "react": "^16.13.1",
    "react-dom": "^16.13.1"

[Widcket]

Hi @vitormv, thanks for raising this.

I created a sample codebox where you can see the issue

Can you please share your reproduction app?

[vitormv]

Ahh sorry, forgot to paste the link above! https://codesandbox.io/s/peaceful-smoke-0iubu

[Widcket]

Hi @vitormv, I was not able to take a look yet. Most likely, I'll get to it by the end of the week.

[Widcket]

@vitormv indeed, this does not happen with Next.js < 11.1.0. Thanks for providing the reproduction app.
cc @adamjmcgrath see vercel/next.js#26629

[adamjmcgrath]

Hi @vitormv - we'll have to investigate what we can do for this.

In the meantime you can workaround it by prefixing the base url to your login url, eg NEXT_PUBLIC_AUTH0_LOGIN="$AUTH0_BASE_URL/api/auth/login"

Just bear in mind that our solution may involve doing this, which would break your workaround.

note to self: we may have to stop using the redirect prop of getServerSideProps https://github.com/auth0/nextjs-auth0/blob/main/src/helpers/with-page-auth-required.ts#L114 - but I remember there was a different issue with using res.writeHead(30x, ...

[RyanClementsHax]

Hello,
This is also a problem I'm running into. Thanks for all the work y'all put behind this repo btw. It is providing me a lot of value.

I took a look into this myself and while I didn't find a workaround/fix, I did notice some patterns I figured I would contribute. All of the following is reproduced in the following reproduction app (it's based on the auth0 nextjs quickstart found here) which demonstrates the same problem @vitormv found.

The first thing I noticed was an error produced when navigating to a protected route using a Link tag when unauthenticated. i.e. you're on localhost:3000, but then click a link to a protected route (ex: ssr). This is also present in the reproduction example from @vitormv. I'm not exactly sure it is related, but I figured I'd mention it since I'm not sure how to interpret the error:

The second thing I noticed was that when the protected url was directly accessed instead of linked to via Link tag, the redirections worked just fine (i.e. href="/ssr" fails, but putting localhost:3000/ssr directly into the browser address bar works just fine). This seems to be a result of the different headers produced between the two actions as evidenced by the diffs below of the get server side props context object.

Note: the diffs are from the personal project of mine where I'm localizing in spanish (es) and trying to link to a protected route called /home from a localized non authenticated page (localhost:3000/es). This is not from the reproduction case. The left side was produced when you would link to a protected route from the localhost:3000/es page and the right side is produced from putting the protected route directly into the address bar. Only parts of the diff were included for bevity. Log out the context object in the reproduction example to see more.

My guess is that the Referer header being set to localhost:3000/es triggers the i18n internals of next thus potentially requiring us to open a ticket with the next repo to get it working the way we need again. (Not sure as I'm not an expert though)

[RyanClementsHax]

In the meantime you can workaround it by prefixing the base url to your login url, eg NEXT_PUBLIC_AUTH0_LOGIN="$AUTH0_BASE_URL/api/auth/login"

I have confirmed that this workaround works in my case (thanks for posting it). I did run into a typing problem when instantiating my own instance of auth0 and figured I'd post it to save the next person some time.

The following should work, but the config type for initAuth0 (found here) doesn't line up with the type used to parse the parameters which includes the login url override (found here).

// lib/auth/auth0.ts or wherever you want to put it
import { initAuth0 } from '@auth0/nextjs-auth0'

export default initAuth0({
  // ... other config
  routes: {
    login: `${process.env.AUTH0_BASE_URL}/api/auth/login`
  }
})

To get around this, I used a type cast like so:

// lib/auth/auth0.ts or wherever you want to put it
import {
  initAuth0,
  ConfigParameters,
} from '@auth0/nextjs-auth0'

export default initAuth0({
  // ... other config
  routes: {
    login: `${process.env.AUTH0_BASE_URL}/api/auth/login`
  }
} as ConfigParameters)

[adamjmcgrath]

Closing this, as the workaround is the best we can offer for now. Will reassess this when considering a next major version