v4 - replacements for with_____Required methods?

[johncarmack1984]

Per the quoted thread, am asking for documentation regarding intended use of the new APIs for those migrating from 3.x.x using methods such as withPageAuthRequired, withMiddlewareAuthRequired, etc.

          Hey folks 👋 For questions pertaining to v4, could I kindly ask you to open separate issues (you can feel free to tag me). This will help keep things on topic and more discoverable for others who might have the same question.

Originally posted by @guabu in https://github.com/auth0/nextjs-auth0/issues/1779#issuecomment-2460099334

[guabu]

Hey @johncarmack1984 👋 Thanks for opening a separate thread! You should be able to use the getSession() method to determine if a user is authenticated and either redirect them or show them a prompt. For example:

import { auth0 } from "@/lib/auth0"

export default async function Home() {
  const session = await auth0.getSession()

  if (!session) {
    return (
      <main>
        <a href="/auth/login?screen_hint=signup">Sign up</a>
        <a href="/auth/login">Log in</a>
      </main>
    )
  }

  return (
    <main>
      <h1>Welcome, {session.user.name}!</h1>
    </main>
  )
}

The same method works in the middleware.

[johncarmack1984]

Ah, I see... low-key was hoping there would be an equally low-boilerplate solution in the new API, but ultimately the API is the API. Will set to work adding the new additional boilerplate to our several hundred pages, thanks for the quick response.

[guabu]

If you'd like to stick to the same wrapper, you can combine the getSession method into a HOC:

import { ComponentType } from "react"
import { redirect } from "next/navigation"

import { auth0 } from "@/lib/auth0"

export function WithPageAuthRequired(Component: ComponentType) {
  return async () => {
    const session = await auth0.getSession()

    if (!session) {
      redirect("/error-page")
    }

    return <Component />
  }
}

[johncarmack1984]

Oh rad, thank you!

[johncarmack1984]

Well... thanks were a bit premature on this one, the wrapper doesn't work. Still can't upgrade.

[guabu]

Well... thanks were a bit premature on this one, the wrapper doesn't work. Still can't upgrade.

Hey @johncarmack1984 👋 That looks to be a eslint-related error coming from the react/display-name rule configured for the project. The following sample should help you satisfy the eslint rule:

import type { ComponentType } from "react"
import { redirect } from "next/navigation"

import { auth0 } from "@/lib/auth0"

type WithPageAuthRequired = (Component: ComponentType) => React.FC

const withPageAuthRequired: WithPageAuthRequired = (Component) => {
  return async function WithPageAuthRequired(props): Promise<JSX.Element> {
    const session = await auth0.getSession()

    if (!session) {
      redirect("/error-page")
    }

    return <Component {...props} />
  }
}

export default withPageAuthRequired

Feel free to adapt it to your needs since the above is meant to be an example of how to create such a wrapper.

[johncarmack1984]

Yes, we use eslint on our team and that is a standard nextjs lint rule, I won't be disabling it so that code that doesn't conform can be merged, as that undermines the purposes of a linter, so I appreciate you modifying the code to comply with the lint rules of the host dependency.

➜  emg-dashboard git:(dev) ✗ bun run build
$ next build
   ▲ Next.js 15.0.3
   - Environments: .env.local

   Creating an optimized production build ...
Failed to compile.

./src/lib/auth0/auth0.ts
Error:   x You're importing a component that needs "server-only". That only works in a Server Component which is not supported in the pages/ directory. Read more: https://nextjs.org/docs/getting-started/
  | react-essentials#server-components
  | 
  | 
   ,-[/emg-dashboard/src/lib/auth0/auth0.ts:1:1]
 1 | import "server-only"
   : ^^^^^^^^^^^^^^^^^^^^
 2 | 
 3 | import { Auth0Client } from "@auth0/nextjs-auth0/server"
 4 | import { env } from "#env"
   `----

Import trace for requested module:
./src/lib/auth0/auth0.ts
./src/lib/auth0/auth0.client.tsx
./src/app/(root)/@user/page.tsx

Looks like the latest recommended implementation would expose confidential information to the client, which was thankfully caught by a different dependency.

[guabu]

No worries, happy to help! 👍

[johncarmack1984]

Uh... right. Thanks for your time guabu, I can see that you're going full effort here, but I'm probably going to recommend we go with another provider in the future, auth0's approach to this upgrade is feeling a little haphazard and the support on these threads has been a little less interested in user outcomes than our stakeholders are comfortable with.

[guabu]

Looks like the latest recommended implementation would expose confidential information to the client, which was thankfully caught by a different dependency.

The example shared above is a server component. If you want to ensure that it's not accidentally used in a client component, Next.js recommends using the server-only package: https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#keeping-server-only-code-out-of-the-client-environment

[johncarmack1984]

The server-only package is not only what caught the leaked confidential information, it is what triggered the error pasted above, and is in fact explicitly present in the error pasted above.

[UrbanLauren]

@guabu Are you an AI bot? Your responses don't make sense

[johncarmack1984]

So... with a week's distance and no response from @guabu on any topic more complex than a simple fix, I'm about convinced @UrbanLauren had it right. Guabu seems to be an AI agent performing the role of lead security software engineer, under the supervision of two individuals who are going behind him and closing GH issues when users quit responding. Either that or he's a junior engineer who has been given an opportunity far beyond his capacity and auth0 has decided to cover for him rather than rectify it.

Do user agreements even have clauses for a maneuver like this? US law certainly has word for it.

[guabu]

@johncarmack1984 what exactly is your follow-up question here? Let's please keep the tone respectful and avoid making such assumptions/statements.

I shared an example of how to achieve something similar to v3's withPageAuthRequired using a server component here: https://github.com/auth0/nextjs-auth0/issues/1790#issuecomment-2468939069

As I mentioned above, the example I shared is a server component and is not meant to be used in a client component.

withPageAuthRequired in v3 is a client component — if you'd like to continue using a client component for withPageAuthRequired you can use the useUser() client-side hook to achieve something similar.

You can find documentation on how to access the user/session where we make a distinction between accessing it on the client and on the server here: https://github.com/auth0/nextjs-auth0/tree/v4?tab=readme-ov-file#accessing-the-authenticated-user

We'll get some examples added to a migration guide to make sure it's clearer for folks but in the meantime if you have specific questions, please let us know.

[johncarmack1984]

@guabu Why would I need a follow up? My original question was never answered. My tone is appropriate considering the amount of legwork I've had to do for what is ostensibly a paid service that has abandoned developer experience in favor of gaslighting and tone policing.

Your original example did not work. It broke our build.

withPageAuthRequired in v3 is a utility function, not a component. It receives a component as an argument, which can be a server component. You can see an example here: https://github.com/auth0/nextjs-auth0/blob/main/example-app/app/profile/page.tsx

I did not ask for how to use the utility in a client component. I asked for a replacement for the original utility.

I tested your example and reported the results, which included the error indicating your example was leaking confidential information to the client via the render. If you found that unsatisfactory, I'd advise you to look inward, and perhaps try to solve the actual problem posed in the thread.

[dustinmyers]

Just started migrating to Next 15, and I'm really disappointed in the nextjs-auth0 team. I wish I had resources to abandon the library as John has, but I cannot. I'm hoping there is someone competent within earshot who can provide a an answer to this issue soon.

[johncarmack1984]

@dustinmyers feeling you Dustin, wish I had the bandwidth to finish my fork and implement the features our team doesn’t need. Sorry man. :-/ If you’re a solo dev and would rather not reward auth0 for the missteps in this thread, supabase is probably the best option for migrating, since you’re in for a major refactor either way.

[brth31]

Thank you for raising these concerns about the v4 migration path. While we aim to provide working solutions in these threads, it's clear we need to improve our migration documentation and examples. As @guabu mentioned earlier, we will add more examples to the migration guide.

We're closing this thread to keep discussions focused on specific technical questions. We appreciate your feedback and will use it to improve our documentation and migration support.

[johncarmack1984]

This issue has not been completed and should not be closed.

[kporterelliott]

well, if i was on the edge of trying to determine if auth0 was something we should use or not... this answers it. How about clerk yall?

[soulwa]

would really be good to have a satisfying answer to this. the migration guide for v4 is still pretty disappointing on this front, 5 months later

[johncarmack1984]

@soulwa the original author of the package got promoted to staff engineer at the holding company, and some middle manager at auth0 gave responsibility for this package to a GitHub account with roughly the reading comprehension and tech support skills of an LLM trained for RAG on the old codebase. I’d just migrate tbh.

[treygilliland]

Agreed on all fronts here -- migrating to Next.js v15 is impossible due to breaking changes migrating to v4. Pages router support is especially lacking.

To anyone who comes across this, stay away from Auth0

[frederikprijck]

Reopening this issue.

Even though it may be a bit too late for the OP given when this issue was opened originally, I do think we should consider bringing these back to reduce migration friction for those who yet have to undergo the migration.

[tusharpandey13]

#2193 was released with v4.8.0, enabling support for withPageAuthRequired in client-side. #2207 is on track to be released soon as well, enabling support for server for the same.

[mickaeltr]

Hello, Thanks for this nice addition (withPageAuthRequired). 👍 Can you please suggest a way to returnTo the original URL when it contains parameters (e.g /protected-page/[slug])?