-
|
Running: Here's the permalink to the Stack Trace on Vercel |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 12 replies
-
|
hi @ztanner In our application, Example of condition and redirect in const isMember = false
if (!isMember) {
return NextResponse.redirect(new URL('/plans', request.url));
}
Hoping we can get a patch soon! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ehis, thank you for the report! This should be fixed by #65097 which is available in |
Beta Was this translation helpful? Give feedback.
-
|
@ztanner Thanks for the callout on Correct, as presumed the end goal is for the middleware to intercept any server action triggered on A practical use case for this flow could be the middleware intercepting an action and redirecting to the If there's another recommended NextJS approach to doing the equivalent would love any suggestions 🙏🏾 |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ehis -- I see, that makes sense! For the use-case you shared, some ideas/recommendations:
export const purchaseMe = async () => {
const isLoggedIn = await verifyAuth()
if (!isLoggedIn) {
redirect('/plans')
}
return {
foo: 'bar',
}
}
|
Beta Was this translation helpful? Give feedback.
-
|
@ztanner I see! If we perform the hard auth check in our server actions could we then exclude them from the middleware? eg. export const config = {
matcher: [
/*
* Match all request paths except for the ones starting with:
* - api (API routes)
* - _next/static (static files)
* - _next/image (image optimization files)
* - favicon.ico (favicon file)
*/
{
source:
'/((?!api|_next/static|_next/image|media|fonts|favicon.ico|favicon.png).*)',
missing: [
// Exclude Server Actions
{ type: 'header', key: 'next-action' },
],
},
],
}; |
Beta Was this translation helpful? Give feedback.
-
|
@ehis, yep, no need to handle in middleware! You can think of it similar to an API route where you'd have the auth check at the top of the request handler. |
Beta Was this translation helpful? Give feedback.
-
|
thanks so much @ztanner and really appreciate the response to the help discussion!! |
Beta Was this translation helpful? Give feedback.
-
|
hey, I had a similar issue, and I could solve it by adding the missing field. However I don't really understand why excluding server actions does the trick, and even more, how is this line excluding server actions ? My use case was an auth process with jwt token and refresh token, that would redirect to login when the session was expired |
Beta Was this translation helpful? Give feedback.
-
|
@Enzo-PVsyst Same in my case. middleware.ts const testAuth = await isAuthenticated();
console.log(testAuth, "in middleware");
if (testAuth) {
return NextResponse.next();
} else {
return NextResponse.redirect(new URL("/login", request.url));
}
}
// matcher config that excludes login and some other essentialslogin/page.tsx "use client";
import { useRouter } from "next/navigation";
import { makeAPICall } from "../utils";
export default function Home() {
const router = useRouter();
const handleSet = async (value: number) => {
await makeAPICall(value); // added this implementation at the end. (utils.ts)
// redirect("/v4") // commented because it's throwing NEXT_REDIRECT error.
router.replace("/v4");
};
return (
<main className="space-x-4">
<button onClick={async () => await handleSet(1)}>Set Cookie</button>
</main>
);
}v4/page.tsx "use client";
import { useRouter } from "next/navigation";
import { makeAPICall, onSubmit } from "../utils";
import clearCachesByServerAction from "@/customCacheClear";
export default function Home() {
const router = useRouter();
const handleSet = async (value: number) => {
await makeAPICall(value);
clearCachesByServerAction("/");
if (value == -1) {
router.replace("/login");
}
};
return (
<main className="space-x-4">
<button onClick={async () => await handleSet(-1)}>Logout</button>
<button onClick={async () => await handleSet(0)}>Get Cookie</button>
<button onClick={async () => await handleSet(1)}>Set Cookie</button>
<button onClick={async () => await handleSet(2)}>Refresh Cookie</button>
</main>
);
}utils.ts "use server"
export const isAuthenticated = async () => {
const value = await getCookie();
if (value) {
return true;
} else {
return false;
}
};
export const setCookie = async () => {
cookies().set("client", "settingCookie");
};
export const deleteCookie = async () => {
cookies().delete("client");
};
export const setNewCookie = async () => {
cookies().set("client", "settingNewCookie");
};
export const getCookie = async () => {
const value = cookies().get("client");
console.log(value?.value ?? "Not found!");
return value?.value;
};clearCacheByServerAction.ts "use server"
import { revalidatePath } from "next/cache"
const clearCachesByServerAction = async (path: any) => {
try {
if (path) {revalidatePath(path)}
else {
revalidatePath("/")
revalidatePath("/[lang]")
}
} catch (error) {
console.error("clearCachesByServerAction=> ", error)
}
}
export default clearCachesByServerActionUse case:When I click on logout, the cookies gets deleted, but still, apparently, in the middleware, the log shows The intended action was to navigate to Now my queries are: Apologies in advance if the queries seem to be silly, since I did not find any proper resource for handling the cookies from route.ts, middleware.ts etc. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ztanner - so to confirm, are you saying that you can't use middleware for auth redirects when using server actions? It would be great if this was supported, or added to the middleware docs as a limitation as it can lead to bugs that are tricky to pin down! |
Beta Was this translation helpful? Give feedback.
-
|
I came across to this problem as well, IMO, having the redirects at middleware level made more sense, instead of duplicating same logic in more than one place ( one at middle ware and others at each server action ). My dependencies: in the export function middleware(request: NextRequest) { } export const config = { |
Beta Was this translation helpful? Give feedback.
@ehis, yep, no need to handle in middleware! You can think of it similar to an API route where you'd have the auth check at the top of the request handler.