Support async API required by Next 15

[Enngage]

Checklist

• [X] I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• [X] I have looked into the API documentation and have not found a suitable solution or answer.
• [X] I have searched the issues and have not found a suitable solution or answer.
• [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• [X] I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

Accessing cookies / headers is now async and the app fails if you access it synchronously in latest canary versions of next 15. More about the change is available within their docs - https://nextjs.org/docs/messages/sync-dynamic-apis

Describe the ideal solution

Implement async handling of cookies - https://nextjs.org/docs/messages/sync-dynamic-apis

Alternatives and current workarounds

There are no workarounds right now, other then staying on older versions of Next 15. Yeah, it's still a Canary version, but we expect to release it soon.

Additional context

No response

[tpiros]

Next.js is now officially live: https://nextjs.org/blog/next-15. It'd be great to have a fix for this as it's now breaking my authentication flow.

[alioftech]

Fix please. Can't upgrade to nextjs 15 before fix

[ciocanraul22]

I see that this issue is already in-view, then I wasted my toime posting on Vercel's github about the issue.

Just for reference: here's what I get in the console: Error: In route /api/auth/[auth0] a param property was accessed directly withparams.auth0.paramsshould be awaited before accessing its properties. Learn more: https://nextjs.org/docs/messages/sync-dynamic-apis

[guabu]

Hi all 👋 We're working on adding support for the dynamic APIs in the upcoming v4 release of the SDK.

[Enngage]

Hi all 👋 We're working on adding support for the dynamic APIs in the upcoming v4 release of the SDK.

That's great to hear @guabu :) Do you by any chance have an estimation of when beta/release will be available?

[guabu]

That's great to hear @guabu :) Do you by any chance have an estimation of when beta/release will be available?

We're working to release the alpha version today and expect to release the beta shortly after (a few days or a couple of weeks at most).

[BogdanManescu]

Next 15 introduced some new breaking! updates, i fixed authentication easily, hint: use await

[steelbrain]

Hi all 👋 We're working on adding support for the dynamic APIs in the upcoming v4 release of the SDK.

That's great to hear @guabu :) Do you by any chance have an estimation of when beta/release will be available?

I understand that we want to release something with SDK v4, but in the meantime, can we get something for people who don't want to migrate to latest Auth0/NextJS but just the latest NextJS?

[guabu]

Hi all 👋 We've just released the v4 alpha which you could try out here.

I understand that we want to release something with SDK v4, but in the meantime, can we get something for people who don't want to migrate to latest Auth0/NextJS but just the latest NextJS?

We definitely plan to address some of the issues in v3 as we understand that not everyone can migrate right away. We did try to keep breaking changes to a minimum but there are certainly differences and we'll be providing a migration guide soon.

However, Next 15 support will most likely not land in v3 as it will require breaking changes.

[steelbrain]

However, Next 15 support will most likely not land in v3 as it will require breaking changes.

I would like to navigate this together! Based on my understanding (and I could be missing something), the only changes that would apply to Auth0/NextJS would be changing cookies() and headers() etc to have an await in front of them.

Based on my understanding of Javascript, await-ing a non-Promise value is a no-op. So it's pretty safe to add that await and say, run Next.js v14 or v13 etc. So those changes would make v3 compatible across the board here.

Thoughts?

[johncarmack1984]

While the auth0 team works on an official solution, I was able to get a fork working with Next 15. Anyone who needs a drop-in solution today is welcome to use it.

bun add github:johncarmack1984/nextjs-auth0#bada487ceaace86195af774a5d361465cb3688d3

[iansbrash]

Here's a patch I created while we wait. Works for me on the dev server (am yet to push this to production) on @auth0/nextjs-auth 3.5.0 and nextjs 15.0.2-canary.5. Check out how to apply this patch here. Hope this helps someone.

diff --git a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateful-session.js b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateful-session.js
index 452c9bc..c05ca52 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateful-session.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateful-session.js
@@ -25,7 +25,7 @@ class StatefulSession extends abstract_session_1.AbstractSession {
     async getSession(req) {
         const config = await this.getConfig(req);
         const { name: sessionName } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         const keys = await this.getKeys(config);
         const sessionId = await (0, signed_cookies_1.getCookieValue)(sessionName, cookies[sessionName], keys);
         if (sessionId) {
@@ -39,7 +39,7 @@ class StatefulSession extends abstract_session_1.AbstractSession {
         const config = await this.getConfig(req);
         const store = await this.getStore(config);
         const { name: sessionName, genId } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         const keys = await this.getKeys(config);
         let sessionId = await (0, signed_cookies_1.getCookieValue)(sessionName, cookies[sessionName], keys);
         // If this is a new session created by a new login we need to remove the old session
@@ -64,7 +64,7 @@ class StatefulSession extends abstract_session_1.AbstractSession {
     async deleteSession(req, res, cookieOptions) {
         const config = await this.getConfig(req);
         const { name: sessionName } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         const keys = await this.getKeys(config);
         const sessionId = await (0, signed_cookies_1.getCookieValue)(sessionName, cookies[sessionName], keys);
         if (sessionId) {
diff --git a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateless-session.js b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateless-session.js
index dac0705..3727a8f 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateless-session.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/session/stateless-session.js
@@ -55,7 +55,7 @@ class StatelessSession extends abstract_session_1.AbstractSession {
     async getSession(req) {
         const config = await this.getConfig(req);
         const { name: sessionName } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         let existingSessionValue;
         if (sessionName in cookies) {
             // get JWE from un-chunked session cookie
@@ -96,7 +96,7 @@ class StatelessSession extends abstract_session_1.AbstractSession {
     async setSession(req, res, session, uat, iat, exp, cookieOptions) {
         const config = await this.getConfig(req);
         const { name: sessionName } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         debug('found session, creating signed session cookie(s) with name %o(.i)', sessionName);
         const [key] = await this.getKeys(config);
         const value = await this.encrypt(session, { iat, uat, exp }, key);
@@ -123,7 +123,7 @@ class StatelessSession extends abstract_session_1.AbstractSession {
     async deleteSession(req, res, cookieOptions) {
         const config = await this.getConfig(req);
         const { name: sessionName } = config.session;
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         for (const cookieName of Object.keys(cookies)) {
             if (cookieName.match(`^${sessionName}(?:\\.\\d)?$`)) {
                 res.clearCookie(cookieName, cookieOptions);
diff --git a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/transient-store.js b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/transient-store.js
index 0cfd094..0931ae7 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/auth0-session/transient-store.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/auth0-session/transient-store.js
@@ -59,7 +59,7 @@ class TransientStore {
      * @return {String|undefined} Cookie value or undefined if cookie was not found.
      */
     async read(key, req, res) {
-        const cookies = req.getCookies();
+        const cookies = await req.getCookies();
         const cookie = cookies[key];
         const config = await this.getConfig(req);
         const cookieConfig = config.transactionCookie;
diff --git a/node_modules/@auth0/nextjs-auth0/dist/handlers/auth.js b/node_modules/@auth0/nextjs-auth0/dist/handlers/auth.js
index 28fa778..8b6e547 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/handlers/auth.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/handlers/auth.js
@@ -38,7 +38,7 @@ exports.default = handlerFactory;
  */
 const appRouteHandlerFactory = (customHandlers, onError) => async (req, ctx) => {
     const { params } = ctx;
-    let route = params.auth0;
+    let route = (await params).auth0;
     if (Array.isArray(route)) {
         let otherRoutes;
         [route, ...otherRoutes] = route;
diff --git a/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-request-cookies.js b/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-request-cookies.js
index 3f948e5..9eb445c 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-request-cookies.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-request-cookies.js
@@ -8,8 +8,11 @@ class Auth0NextRequestCookies extends http_1.Auth0RequestCookies {
     getCookies() {
         // eslint-disable-next-line @typescript-eslint/no-var-requires
         const { cookies } = require('next/headers');
-        const cookieStore = cookies();
-        return cookieStore.getAll().reduce((memo, { name, value }) => (Object.assign(Object.assign({}, memo), { [name]: value })), {});
+        return cookies().then((cookieStore) => {
+            return cookieStore
+                .getAll()
+                .reduce((memo, { name, value }) => (Object.assign(Object.assign({}, memo), { [name]: value })), {});
+        });
     }
 }
 exports.default = Auth0NextRequestCookies;
diff --git a/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-response-cookies.js b/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-response-cookies.js
index ea7e5e4..0df54c5 100644
--- a/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-response-cookies.js
+++ b/node_modules/@auth0/nextjs-auth0/dist/http/auth0-next-response-cookies.js
@@ -17,24 +17,30 @@ class Auth0NextResponseCookies extends http_1.Auth0ResponseCookies {
     setCookie(name, value, options) {
         // eslint-disable-next-line @typescript-eslint/no-var-requires
         const { cookies } = require('next/headers');
-        const cookieSetter = cookies();
-        try {
-            cookieSetter.set(Object.assign(Object.assign({}, options), { name, value }));
-        }
-        catch (_) {
-            warn();
-        }
+         cookies().then((cookieSetter) => {
+            try {
+                cookieSetter.set(
+                    Object.assign(Object.assign({}, options), {
+                        name,
+                        value,
+                    })
+                );
+            } catch (_) {
+                warn();
+            }
+        })
     }
     clearCookie(name, options) {
         // eslint-disable-next-line @typescript-eslint/no-var-requires
         const { cookies } = require('next/headers');
-        const cookieSetter = cookies();
-        try {
-            cookieSetter.set(Object.assign(Object.assign({}, options), { name, value: '', expires: new Date(0) }));
-        }
-        catch (_) {
-            warn();
-        }
+        cookies().then((cookieSetter) => {
+            try {
+                cookieSetter.set(Object.assign(Object.assign({}, options), { name, value: '', expires: new Date(0) }));
+            }
+            catch (_) {
+                warn();
+            }
+        })
     }
 }
 exports.default = Auth0NextResponseCookies;
diff --git a/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-request-cookies.ts b/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-request-cookies.ts
index dd93945..d06856d 100644
--- a/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-request-cookies.ts
+++ b/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-request-cookies.ts
@@ -8,13 +8,15 @@ export default class Auth0NextRequestCookies extends Auth0RequestCookies {
   public getCookies(): Record<string, string> {
     // eslint-disable-next-line @typescript-eslint/no-var-requires
     const { cookies } = require('next/headers');
-    const cookieStore = cookies();
-    return cookieStore.getAll().reduce(
-      (memo: Record<string, string>, { name, value }: { name: string; value: string }) => ({
+    return cookies().then((cookieStore) => {
+      console.log('cookieStore', cookieStore);
+      return cookieStore.getAll().reduce(
+        (memo: Record<string, string>, { name, value }: { name: string; value: string }) => ({
         ...memo,
         [name]: value
       }),
-      {}
-    );
+        {}
+      );
+    });
   }
 }
diff --git a/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-response-cookies.ts b/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-response-cookies.ts
index c690479..a511603 100644
--- a/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-response-cookies.ts
+++ b/node_modules/@auth0/nextjs-auth0/src/http/auth0-next-response-cookies.ts
@@ -22,22 +22,25 @@ export default class Auth0NextResponseCookies extends Auth0ResponseCookies {
   public setCookie(name: string, value: string, options?: CookieSerializeOptions) {
     // eslint-disable-next-line @typescript-eslint/no-var-requires
     const { cookies } = require('next/headers');
-    const cookieSetter = cookies();
-    try {
-      cookieSetter.set({ ...options, name, value });
-    } catch (_) {
-      warn();
-    }
+    cookies().then((cookieSetter) => {
+      try {
+        cookieSetter.set({ ...options, name, value });
+      } catch (_) {
+        warn();
+      }
+    });
   }

   public clearCookie(name: string, options?: CookieSerializeOptions) {
     // eslint-disable-next-line @typescript-eslint/no-var-requires
     const { cookies } = require('next/headers');
-    const cookieSetter = cookies();
-    try {
-      cookieSetter.set({ ...options, name, value: '', expires: new Date(0) });
-    } catch (_) {
-      warn();
-    }
+    cookies().then((cookieSetter) => {
+        try {
+          cookieSetter.set({ ...options, name, value: '', expires: new Date(0) });
+        } catch (_) {
+          warn();
+        }
+    })
+    
   }
 }

@auth0+nextjs-auth0+3.5.0.patch

[mikebywaters]

Thanks @iansbrash

Here's a yarn patch for anyone using yarn >2 who also wants support now and doesn't want to use the v4 alpha

@auth0-nextjs-auth0-npm-3.5.0-2a90316d19.patch

yarn patch docs

[aidanhchau]

any updates / expected dates for when this issue will be resolved? quite significant blocker for us.

[guabu]

Hey all 👋 We're currently discussing this and will share an update on whether we'll be adding support for Next 15 in v3 of the SDK or recommending the upgrade to v4.

We should have a more concrete answer this week!

[dawiddominiak]

@guabu Are you planning to add documentation/description how to chain the v4 middleware with other middlewares?

[guabu]

@guabu Are you planning to add documentation/description how to chain the v4 middleware with other middlewares?

Hey @dawiddominiak 👋 Thanks for trying out the alpha and for the feedback. I'll make a note to make sure we provide an example in the docs on how to combine middleware. To give you something to work with for the time being, you should be able to do something like so:

export async function middleware(request: NextRequest) {
  const authResponse = await auth0.middleware(request)

  // if path starts with /auth, let the auth middleware handle it
  if (request.nextUrl.pathname.startsWith("/auth")) {
    return authResponse
  }

  // call any other middleware here
  const someOtherResponse = await someOtherMiddleware(request)

  // add any headers to the response
  for (const [key, value] of authResponse.headers) {
    someOtherResponse.headers.set(key, value)
  }

  // combine the responses
  return someOtherResponse
}

If you have any follow-up questions about this, could you kindly create a new issue so we can keep this one focused on the Dynamic APIs, please? Feel free to tag me in it so I can be sure to get to get to you right away!

[willedanielsson]

Hey all 👋 We're currently discussing this and will share an update on whether we'll be adding support for Next 15 in v3 of the SDK or recommending the upgrade to v4.

We should have a more concrete answer this week!

Any update on if your planning to have the Next15 support for V3 or if its only for V4? Would be nice to have it in V3 in order to first upgrade Next and then be able to upgrade to V4 but if it's hazzle then it's fine to do both upgrades at once 👍

[vladislavbogomolov]

how does it work in v4?

export default withMiddlewareAuthRequired();

export const config = {
  matcher: ['/api/:path*', '/dashboard/:path*'],
};

[guabu]

Apologies for the delay here, I wanted to make sure we had something concrete to share before getting back to everyone!

We've decided that the best path forward would be to only support Next 15 in the new version (v4) of the SDK. The primary reasons being that we've fixed a number of bugs that have been reported by the community and greatly simplified the architecture and configuration.

Also, we believe it's a good opportunity to encourage folks to upgrade if they're looking to upgrade major versions of Next.js as well. This will also enable us to keep up to date with the latest Next.js features and versions.

We tried to keep breaking changes to a minimum and would encourage you to give it a try. For simple use-cases, the migration should be straight-forward. However, if you do run into any hiccups or have a more complex use-case with the SDK, please feel free to create an issue and we'll work together on it!

You can find the beta version of v4 (with Next 15 support) here with instructions on how to get set up and an example using shadcn: https://www.npmjs.com/package/@auth0/nextjs-auth0/v/4.0.0-beta.0

[johncarmack1984]

No plan to replace withPageAuthRequired? Gonna be a painful migration 😣

[vladislavbogomolov]

I think considering that version 15 has already been released, I think it would be useful to first release update 3.6.0 with support for 15 and only then concentrate on 4

[brndt]

Apologies for the delay here, I wanted to make sure we had something concrete to share before getting back to everyone!

We've decided that the best path forward would be to only support Next 15 in the new version (v4) of the SDK. The primary reasons being that we've fixed a number of bugs that have been reported by the community and greatly simplified the architecture and configuration.

Also, we believe it's a good opportunity to encourage folks to upgrade if they're looking to upgrade major versions of Next.js as well. This will also enable us to keep up to date with the latest Next.js features and versions.

We tried to keep breaking changes to a minimum and would encourage you to give it a try. For simple use-cases, the migration should be straight-forward. However, if you do run into any hiccups or have a more complex use-case with the SDK, please feel free to create an issue and we'll work together on it!

You can find the beta version of v4 (with Next 15 support) here with instructions on how to get set up and an example using shadcn: https://www.npmjs.com/package/@auth0/nextjs-auth0/v/4.0.0-beta.0

Where can I find some example of how to test it using the new API? Before I was mocking UserProvider but it's different now.

[lheilmann]

Is there an equivalent to withMiddlewareAuthRequired?

[guabu]

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.

[mikebywaters]

Apologies for the delay here, I wanted to make sure we had something concrete to share before getting back to everyone!

We've decided that the best path forward would be to only support Next 15 in the new version (v4) of the SDK. The primary reasons being that we've fixed a number of bugs that have been reported by the community and greatly simplified the architecture and configuration.

Also, we believe it's a good opportunity to encourage folks to upgrade if they're looking to upgrade major versions of Next.js as well. This will also enable us to keep up to date with the latest Next.js features and versions.

We tried to keep breaking changes to a minimum and would encourage you to give it a try. For simple use-cases, the migration should be straight-forward. However, if you do run into any hiccups or have a more complex use-case with the SDK, please feel free to create an issue and we'll work together on it!

You can find the beta version of v4 (with Next 15 support) here with instructions on how to get set up and an example using shadcn: https://www.npmjs.com/package/@auth0/nextjs-auth0/v/4.0.0-beta.0

I'll add for the record that this is a terrible decision. This is the exact use-case for the patch semver number, and there are backwards compatible patches in this very thread that it would take mere minutes for someone to implement - could have just done that instead of having a meeting about it. It's not kind to your user base to require them to upgrade major versions (to a beta no less) for such a simple change.

[johncarmack1984]

Speaking as the authors of one of those patches, while I might have phrased it a more delicately, I don't disagree that I would be one of the engineers in that meeting saying "our legacy and future users will appreciate us not requiring them to update two dependencies with breaking changes simultaneously. Let's try some of these open source contributions and see if they pass QA. Shouldn't take more than a couple of hours."

But I've been on teams where nobody wants to maintain what the last team wrote anymore, so I can understand the temptation to use this as a push for that ground-up rewrite the team's been wanting to do.

Ultimately, whether to meet expectations of legacy users of the company's [checks] sixth most popular repository is a business problem; if there's no perceived loss of revenue from business users switching because engineers got tired of maintaining the auth0 dependency, the man-hours expended are hard to justify. But if my employers are any indication, they're a little tired of me delaying features because I had to upgrade auth0 again.

[guabu]

Hey @mikebywaters @johncarmack1984 👋 I understand where you're coming from and I want to make sure we're taking the community's feedback into account when making these decisions.

Just to be clear, Next.js 15 still allows calling these methods synchronously and will just log a warning in development (source from Next.js docs):

In the version of Next.js that issued this warning, access to these properties is still possible directly but will warn. In future versions, these APIs will be async and direct access will not work as expected.

This means you should still be able to stick with v3 of the SDK and use Next 15 if you're not ready to migrate to v4 of the SDK.

I understand the warnings might be a bit of annoyance but I wanted to confirm if you're experiencing something unexpected other than the warning logs?

[johncarmack1984]

Well… my frustration is that auth0 is taking way too much time to maintain, so I’m not really interested in using my free time on a Saturday to write up a detailed report of the error messages and broken login experience I got when doing the upgrade, and I don’t really appreciate the feaux-concern minimizing tone of the response here that implies I took the time to write a patch because I didn’t like a console warning, but I’ll give the upgrade another shot when I’ve got the bandwidth and get back to you if my bosses don’t have us switch to workos next week.

[guabu]

Hey @johncarmack1984 👋

I didn't mean to come off that way at all, that wasn't the intention. It was an honest question to try to understand what issues you ran into since Next 15 documents that the Dynamic APIs can still be accessed asynchronously but will log warnings.

My goal was to know if the errors you were running into were related to the Dynamic APIs or something else.

[johncarmack1984]

Hey @guabu 👋

My goal was to know if the errors you were running into were related to the Dynamic APIs or something else.

To answer this, now that I'm back at my desk and have been given another two hours to troubleshoot auth0 before we move on: I can't get that far. As mentioned in this thread, much of this application is built around the withPageAuthRequired method, which was the officially recommended implementation of app router pages (when not deploying on edge) for the past two years.

With the recommended fix failing to compile due to linting errors, I have no straightforward way of troubleshooting whether it's an auth0 problem or a NextJS problem, which is why it's such a pain to have two dependencies issue breaking changes simultaneously.

[guabu]

Thanks @johncarmack1984! I've responded to the other thread with a sample that should hopefully help satisfy the eslint error you're seeing. Let me know how it goes and I can work with you to make sure we resolve any blockers that pop up!

[johncarmack1984]

As mentioned in the other thread, the lint rule violation you recommended is now fixed but the new recommended fix leaks confidential information to the client.

[mkirch]

As others have indicated, this situation has prompted concerns about the organizational allocation of resources to this project, extending beyond the work of the team and individuals. I appreciate and do not envy @guabu and others for addressing and responding to the raised issues. Given the security and trust that customers place in Auth0, it is unexpected that there are not more formal communications and official anticipation of upstream changes for major frameworks such as Next. Timely and thorough updates with clear documentation and examples are a necessity.

[alexbaileyuk]

Based on the information found at https://nextjs.org/docs/messages/sync-dynamic-apis, this is not broken right now.

In the version of Next.js that issued this warning, access to these properties is still possible directly but will warn. In future versions, these APIs will be async and direct access will not work as expected.

What is interesting is that this actually shows up in the console as an "error":

Error: Route "/api/auth/[auth0]" used `params.auth0`. `params` should be awaited before using its properties. Learn more: https://nextjs.org/docs/messages/sync-dynamic-apis
    at createParamsAccessError (webpack://next/dist/src/server/request/params.ts:467:9)
    at getMessage (webpack://next/dist/src/server/create-deduped-by-callsite-server-error-logger.ts:46:20)
    at warnForSyncAccess (webpack://next/dist/src/server/request/params.ts:445:4)
    at syncIODev (webpack://next/dist/src/server/request/params.ts:403:10)
    at run (webpack://next/dist/src/server/route-modules/app-route/module.ts:529:41)
    at handler (webpack://next/dist/src/server/route-modules/app-route/module.ts:725:18)
    at fn (node_modules/next/src/server/lib/trace/tracer.ts:351:27)
    at NoopContextManager.with (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:7062)
    at ContextAPI.with (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:518)
    at NoopTracer.startActiveSpan (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:18093)
    at ProxyTracer.startActiveSpan (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:18854)
    at startActiveSpan (node_modules/next/src/server/lib/trace/tracer.ts:304:31)
    at NoopContextManager.with (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:7062)
    at ContextAPI.with (/home/hidden/hidden/hidden/node_modules/next/dist/compiled/@opentelemetry/api/index.js:1:518)
    at spanContext (node_modules/next/src/server/lib/trace/tracer.ts:303:24)
    at trace (webpack://next/dist/src/server/route-modules/app-route/module.ts:715:26)
    at run (webpack://next/dist/src/server/route-modules/app-route/module.ts:662:32)
    at run (webpack://next/dist/src/server/route-modules/app-route/module.ts:661:34)
    at run (webpack://next/dist/src/server/route-modules/app-route/module.ts:658:60)
    at handle (node_modules/next/src/server/base-server.ts:2504:47)
    at doRender (node_modules/next/src/server/base-server.ts:3027:27)
    at responseGenerator (node_modules/next/src/server/response-cache/index.ts:67:13)
    at get (node_modules/next/src/server/base-server.ts:3039:48)

This is a little confusing to read. Functionality for v3 still seems to work with Next15 based on my limited testing so perhaps this is just how it's shown from Next?

Either way, since v4 is enroute already and assuming nothing is actually broken here, it does make sense to wait until v4 is ready imo.

[johncarmack1984]

Based on the information found at https://nextjs.org/docs/messages/sync-dynamic-apis, this is not broken right now.

Very important to preface that with "for our repository." Nothing is broken for you based on that warning. Plenty of people in here having broken experiences, despite what the NextJS docs and your personal experience say should happen.

[johncarmack1984]

In 25 years of writing software, honestly can't think of a worse experience I've had in open source than this thread; I came here ready to cooperate on a solution and find a path forward, but after being repeatedly told I can't possibly be experiencing what I am 100% experiencing while being encouraged to use alpha release security software written by an account with zero commits to the previous release, meanwhile perfectly valid patches from the community are ignored entirely... well, I'm not having a great time. Auth0 has been my go-to for clients for years, but I don't think I'll ever recommend them again.

[alexbaileyuk]

@johncarmack1984 appologies my mistake. I understood that it wasn't actually breaking.

[portal7]

The truth is frustrating, you try to start implementing and vercel nextjs recommends moving to nextjs 15, the adventure begins and you realize that everything it says in the documentation does not work or works halfway and you start to have errors such as auth0 async await parameters.

After literally wasting more than 16 hours trying to “make it work”, I fall in the crude reality that “to make it work” you have to use the v4 package, at the same time, this changes absolutely EVERYTHING in the way you do the setup (when with the current version “it works -halfway-”).

Another frustrating thing is that you have to make a “Regular Web App”. Why? until now I could work without problems with the SinglePage.
On the other hand (and finally) to see that all that effort ends in nothing and forces one to return to a previous version to “make it work” ends up taking away the desire to implement both Auth0, as NextJS.

[Abhid14]

As a paying customer, I have concerns about the current state of Auth0's Next.js support. The lack of timely updates for Next.js 15 compatibility is impacting our business operations. While competitors like Clerk have proactively provided first-party support for Next.js 15, we're experiencing challenges with Auth0's integration.

We've invested in Auth0 as our authentication solution, and we would greatly appreciate more proactive framework support, particularly for widely adopted frameworks like Next.js. This would help organizations like ours maintain efficient development cycles and ensure smooth authentication flows in our applications.

Could you please provide an update on the roadmap for official Next.js 15 support? We literally have a major release to ship tomorrow and we are still awaiting Auth0's SDK support for Next.js 15.

[brth31]

Hello everyone, We're thrilled to announce the beta release of nextjs-auth0 SDK v4! This new version brings significant improvements, new features, and fixes to enhance your development experience.

⚠️ Important Notice About v3

As we move forward, we will not be updating v3 of the SDK to support Next.js 15. This allows us to focus on v4, which offers a wealth of new features and improvements. This will also enable us to support future releases of Next.js faster and with more confidence. We understand this may pose challenges, and we're here to help.

v3 will continue to receive critical security updates for 6 months after the GA of v4. We appreciate your understanding as we focus on making v4 the best it can be.

Read the full release announcement here: https://auth0.com/changelog#2o4tKtDIj8rkVTLtPFVnMP

[johncarmack1984]

Your announcement is quite bold considering the problems your users in this thread are having that are being ignored.

[steelbrain]

It is going to be the one month anniversary of Next.js v15 release soon. It’s disappointing that even the new release that’s supposed to support it is in beta, and was announced in a comment 30 minutes ago. I would have preferred if there was a release with just the Next.js compatibility bits, but whatever, at least give me something stable, and give it to me some 3 weeks ago.

We’re paying a lot for this at work. This is forgivable on an open source project, not on a commercial project we’re paying for. Now on top of regular work, I have to put in the plan to get us off of Auth0 in the next few quarters.

As for the release path, not releasing something that supports a new nextjs is very questionable leadership. This is not the Auth0 JavaScript package, this is the Auth0 NextJS compatibility package. The whole purpose of existence of this package is compatibility. Another thing that people tend to forget is that numbers are free. It’s better to have a version 150 where you were hyper compatible and released often over version 5 where you kept your paying clients blocked and didnt match NextJS releases.

[Abhid14]

@steelbrain I completely agree. The Auth0 team has significant catching up to do with their competitors regarding SDK support. I want a clean, easy, and fast way to retrieve additional user data like roles and permissions in my React Server Components and Next.js middleware. However, the path to retrieving or modifying these details is either missing, outdated, or very confusing. The current team or leadership managing this library seems to lack competence, which is concerning given the potentially huge cost for companies to migrate away from Auth0. I don't understand how Okta got to sponsor at the Next.js conference while their most important library and features aren't up to par with the framework, competitors or at least meeting developer expectations.

Auth0 is lacking by 3 years in terms of how much open-source counter parts and auth solutions provides to a developer who has to deal with these issues as they work at an organization using Auth0 as the auth solution.

[paradimes]

Your announcement is quite bold considering the problems your users in this thread are having that are being ignored.

you can look into using the standard auth0 react library (https://www.npmjs.com/package/@auth0/auth0-react), or even auth0 js library. also take a look at next-auth

[johncarmack1984]

you can look into using the standard auth0 react library (https://www.npmjs.com/package/@auth0/auth0-react), or even auth0 js library. also take a look at next-auth

We have opted to remove auth0 from our stack as of today.

[kcolemangt]

Hey @johncarmack1984 - where'd you end up? After dealing with Auth0's Angular 'support' for years, I'm ready to move on. How's the new solution working out?

[johncarmack1984]

Hey @johncarmack1984 - where'd you end up? After dealing with Auth0's Angular 'support' for years, I'm ready to move on. How's the new solution working out?

We like the security of server auth and our relationship with Okta idp is fine, so our devops team is building an OIDC connector directly to the services we are using to communicate with Okta. We're simply removing auth0 from the equation, as the burden of maintenance outweighed the benefit we were receiving for the price. Too early to say how satisfied we are, but OIDC isn't so complicated it's impossible to implement, it's just that until recently using auth0 was easier, so I imagine we'll be as pleased with Okta as we've ever been, and our devops team will be pleased with their new team member, whose job it is to make sure I never have to talk to guabu again. Actually I take it back I'm very pleased.

[ajwootto]

Has anyone had success deploying one of the above patches? I use the middleware auth handler to wrap all my application requests in Auth, and I'm seeing strange behaviour right now with the patch applied where it works running locally, but not when deployed to Vercel. When deployed, it seems like some requests pass the auth middleware and others (namely XHR requests) end up failing.

[johncarmack1984]

@ajwootto If you're using the one I wrote, there's a simple explanation... I didn't implement that method, as our team doesn't use edge deployments, and therefore wasn't a candidate for middleware auth in v3.

If you wanted to PR into the fork, here's the line where I commented out the middleware method, might not be too tough of a fix if you've got the time! But totally understandable if there's no bandwidth!