-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to getAccessToken
for some users on Vercel Deployment
#1045
Comments
Note: I noticed that some sessions come as |
Update:By dropping
import type { NextRequest } from "next/server";
import { NextResponse } from "next/server";
import auth0 from "util/auth0-edge";
const middleware = async (req: NextRequest) => {
const res = NextResponse.next();
const user = await auth0.getSession(req, res);
if (user) {
return NextResponse.next();
}
const baseURL = process.env.VERCEL_URL
? `https://${process.env.VERCEL_URL}`
: process.env.AUTH0_BASE_URL;
return NextResponse.redirect(`${baseURL}/api/auth/login`);
};
export const config = {
matcher: ["/", "/nonprofit/:path*", "/foundation/:path*", "/admin:path*"],
};
export default middleware; |
Thanks for raising this @jonahallibone - I'll investigate this and get back to |
Hi @jonahallibone - this looks like a bug in the vercel edge runtime, which will shortly be fixed by vercel/edge-runtime#255 I'll keep this open until that is released and hopefully you can confirm it's working |
@adamjmcgrath Great! |
Gonna close this in favour of vercel/next.js#38302 - when that's shipped you should be able to update the next version to fix |
@adamjmcgrath We are facing similar issue and it's too random for us to deal with it This is our version
This is our configurationimport {
AuthError,
handleAuth,
handleCallback,
handleLogin,
handleLogout,
} from "@auth0/nextjs-auth0";
import { NextApiRequest } from "next";
const audience = process.env.AUTH0_OAUTH_AUDIENCE;
const scope = process.env.AUTH0_OAUTH_SCOPE;
function getUrls(req: NextApiRequest) {
const { host } = req.headers;
const protocol = process.env.VERCEL_URL ? "https" : "http";
const redirectUri = `${protocol}://${host}/api/auth/callback`;
const returnTo = `${protocol}://${host}`;
return {
redirectUri,
returnTo,
};
}
export default handleAuth({
async login(req, res) {
try {
const { redirectUri, returnTo } = getUrls(req);
await handleLogin(req, res, {
authorizationParams: {
prompt: "login",
audience,
scope,
redirect_uri: redirectUri,
},
returnTo,
});
} catch (error) {
if (error instanceof AuthError) {
res.status(error.status || 400).end(error.message);
}
}
},
async callback(req, res) {
try {
const { redirectUri } = getUrls(req);
await handleCallback(req, res, {
redirectUri,
authorizationParams: {
audience,
scope,
},
});
} catch (error) {
if (error instanceof AuthError) {
res.status(error.status || 500).end(error.message);
}
}
},
async logout(req, res) {
const { returnTo } = getUrls(req);
await handleLogout(req, res, {
returnTo,
});
},
}); We are using this api to get accessTokenimport { getAccessToken, withApiAuthRequired } from "@auth0/nextjs-auth0";
import { NextApiHandler } from "next";
const handler: NextApiHandler = async (req, res) => {
try {
const { accessToken } = await getAccessToken(req, res);
res.status(200).json({ accessToken });
} catch (err) {
console.error(err);
res.redirect(307, "/api/auth/login");
}
};
export default withApiAuthRequired(handler); I think we are in the similar issue as @jonahallibone . Because the user can't login has two session. We try to alter the get-access-token to make this work but there has no luck import { getAccessToken, getSession } from "@auth0/nextjs-auth0";
import { NextApiHandler } from "next";
const handler: NextApiHandler = async (req, res) => {
const user = await getSession(req, res);
if (!user || !user.accessToken) { // <---- can not get the access token
res.redirect(307, "/api/auth/login");
return;
}
res.status(200).json({ accessToken: user?.accessToken });
};
export default handler; Can you provide some workaround before Vercel fix their problem? This has already affected our users |
@adamjmcgrath @jonahallibone I think there Is still actually an issue with https://github.com/auth0/nextjs-auth0/blob/main/src/utils/middleware-cookies.ts#L11 - even after the NextJS issue referenced above has been resolved. I ran into this when implementing the suggestion described in #912. My use case was wanting to have an api proxy that runs on edge (to avoid occasional delays due to cold starts of a regular nodejs api route). The basic problem here is that browsers expect multiple set-cookie headers, one for each cookie. the NextJS bug referenced above made it so instead a single comma-separated set-cookie header was returned. In the case where the auth0 cookie needs to be chunked this was causing a bad value for it to be stored at the browser, and subsequently retrieving session would no longer work. With the NextJS bug fixed, it will correctly return multiple set-cookie headers from an edge route - but only if you call |
Checklist
Description
Currently we are using Next.js api routes to get an
accessToken
to interact with our api server.For one user, we are unable to use
getAccessToken()
in production. On our local deployments the problem does not exist. Every other user can get anaccessToken
withgetAccessToken()
just fine. In fact, it seems that their session is created incorrectly, or is just removed entirely.withMiddlewareAuthRequired
allows the app to navigate to the app, but upon arrival it fails to access/auth/api/me
or any of our api routes which require authentication.We are using this in conjunction with
withMiddlewareAuthRequired()
and deploying to Vercel.The error we recieve in our server logs is the following:
In order to deploy to Vercel we have the following code:
[...auth0].ts
[...proxy].ts
middleware.ts
util/auth0.ts
util/auth0-edge.ts
I'm not sure if this is a bug or not, but it's incredibly hard to understand why the deployed app would be having a problem whilst the local one is fine.
Thanks!
Reproduction
Using the above example in a standard app should work.
SDK version
2.2.1
Next.js version
13.1.5
Node.js version
18
The text was updated successfully, but these errors were encountered: