Sadly, the http 401 standard does not mention anything of supporting a new location. A client, of course, could implement it themself, but is not expected to - some clients may only redirect on 301, 302, 307 & 308. In such case you could use redirect() .

see the updated docs in this PR for an example of redirecting on error:

• support cause in Next.js error signals #73665

This does however not handle the case of redirecting back to the start point.

Here's an example which does that: https://gfcw3s-3001.csb.app/examples/redirect

The way it works is that unauthorized.js renders a client component which redirects the user to `/sign-in?redirectUrl=${window.location.href}`. Once the user signs-in, they are redirected back to the original page.

Alternatively, we should be able to just render <SignInPage> inline inside unauthorized.js. As the URL doesn't change, once the user signs-in then the page should just reload and be authorized. But that doesn't seem to be working for me. Here's an example: https://gfcw3s-3001.csb.app/examples/inline

It seems that, after setting the session cookie, the page does a soft-reload but remains on unauthorized.js. It's not until I do a hard-reload that I see page.tsx. My expectation is that setting a cookie should reset the interrupt, and return to page.tsx. Any ideas, @ztanner?

https://codesandbox.io/p/devbox/gfcw3s

Thank you for the replies! 😃 Actually, I think what is important is that the user is shown the sign-in page (without any extra clicks) upon unauthenticated access, and is shown the original page (without any extra clicks) upon successful authentication.

In particular, I am concerned about obtaining a reference to the original page in generic way. Accessing the current URL is a known issue (see also #43704, #46618, #58212, #65282, #73800).

It seems that, after setting the session cookie, the page does a soft-reload but remains on unauthorized.js. It's not until I do a hard-reload that I see page.tsx. My expectation is that setting a cookie should reset the interrupt, and return to page.tsx.

I think that might be expected behavior. I think it might be the same as revalidatePath ("only invalidates the cache when the included path is next visited"), so a reload or redirect is needed.

I put together a similar demo with inline sign-in, but using a redirect: https://next-sign-in-in-place.vercel.app/ (source code).

For the redirect URL, I used the HTTP referer header. However, that header generally isn't reliable, so it would be good to have an alternative mechanism.

Another issue is the flash of white between redirects. That's to be expected, but it would be nice to eliminate it.

I think if Next.js provided a server-side refresh() function to trigger a client-side refresh, it could potentially address both problems.

Regarding the redirect, see #73753 (reply in thread)

For webpages I think they now covered all possible return status codes that could render complete pages differently, other status codes are more meant for API endpoints? Instead of using the HTTP code as file name, it's easier to know what the file is for, instead of mapping the HTTP code to the correct meaning in your head or having to search what the HTTP code meant again.

What about a 500 or 503 if my database is down? Return a 201 from a server action? Creating a new set of web standards that are not portable and only specific to next.js is weird, and one of the common criticisms of this framework. Just let us lean on the standards and re-use our existing knowledge.

You can throw a 500 by throwing an error (throw new Error()), which will then render the error.tsx. Gotta agree on the server-actions part, that is weird

Passing down a cause will be possible once this is merged:

• support cause in Next.js error signals #73665

Edit: after reading your question and the PR again, the payload might not be available on the error page, but only when catching the error 🤔

You could technically stringify some data into the error message then parse it out. The error passed into the function will be passed down as the cause prop to the error page

I wrote a feature request proposing this.

I like the approach in the PR: the payload gets attached as the cause.

@ztanner, is the intention to allow cause to be read from unauthorized.js and forbidden.js, presumably with a reset function as well?

This could be a possible solution:

• Introduce experimental Request Interceptors #70961

Thats great!. This is exactly what i am looking for. Is this feature already available in the current canary build?
Thanks for sharing these details.

See this PR:

• support cause in Next.js error signals #73665

Yes that might help but is not quite solving the problem yet.

Because the response has already been sent (is being sent, as part of the streaming). These methods cause the rendering to be interrupted and a soft-redirect is made from the client, but the status is always 200.

Well but we don't care so much about the status code but about the error message we display to the user.
For example, there is currently no chance to properly display 50x messages to the user.

ok, can make sense to use it inside server actions

Hi @colinclerk , the general idea is that these interrupt style functions like notFound and forbidden are maybe best reserved for invariant cases. For instance if you have no recourse (like reverifying the user) and we just need to render some UI which communicates the intent. They're a decent proxy for when that same request would be a 401/403/404 for a traditional HTTP server serving static files.

So you might use forbidden in a protect API which terminates the current code (like don't actually execute this query b/c you aren't allowed to access this data) but you would want to catch this and handle it to enrich the situation.

function protect(fn) {
 // figure out if this users is allowed to do the thing
 if (!allowed) {
 const cause = {
 code: NEEDS_REVERIFICATION,
 details: ...// whatever you need here
 }
 forbidden(cause)
 }
 return fn()
}
// user code
async function getSensitiveData() {
 return protect(() => db.query(...))
}
// server function using getSensitiveData indirectly
async function doAction() {
 "use server"
 return protectAction(() => {
 return doStuffThatDeeplyCallsGetSensitiveData()
 })
}
// protectAction definition
function protectAction(fn) {
 try {
 return await fn()
 } catch (e) {
 let cause = e.cause
 while(cause) {
 if (isProtectedCause(cause)) {
 return ... // something that the auth framework on the client can understand
 }
 if (typeof cause !== 'object') {
 break
 }
 
 // go deeper maybe something wrapped our protect cause
 cause = cause.cause
 }
 }
 // if we got here then the error isn't some protection error, we can let it bubble up
 throw e
}

On the client you'd need to have a way to interpret the protection return value. It might look like

"use client"
function Page({ serverAction }) {
 const [protectedState, formAction] = useActionState(serverAction, initialState)
 
 // We need to handle the protected return value here
 // If the protected state were something exceptional like needs reverification then you'd
 // maybe throw here and have some auth library error handler handle it. crucially you have whatever data
 // you needed to pass through to this consumer such as the `{ code: NEEDS_REVERIFICATION, details: ... }` from above
 const state = useProtectedState(protectedState)
 
 // At this point state is now just the normal value returned by the server action inner function
}

So if you use forbidden in protect in this example but you forget to use protectAction on the server as a safety fallback the forbidden boundary will be triggered on the client. But this very likely isn't the best UX and users will want to implement that better UX using the protectAction and useProtectedState hooks to give them more control over handling exceptional cases based on the details relevant to that case. This is just a sketch of how you might implement auth utils library. Certainly there are other valid ways to set this up but using the return style rather than throw style is how we imagine the "good UX" pattern would be implemented.

One thing that I'm curious about from your specific example is why the reverification needs to happen on the client. if all that needs to happen to make this action possible is a refresh then performing said refresh within the action itself seems preferable. If that's not possible then using forbidden (or even the aforementioned useProtectedState) is a little tricky because it'll destroy the local state of the page to render the forbidden page and so even if the error boundary ends up reverifying the user when the components remount the local state will have been lost. Solvable with things like controlled components maybe but not an insigificant consequence of relying on the throwing behavior of forbidden.

cc @ztanner

I agree, this is a very common use case. We were discussing it in #73753 (comment).

My take is that, instead of a link to a sign-in form, you could show the sign-in form in place of the restricted content. Thus the browser would still be at the desired URL. Then on a successful sign-in (via a server action), you could somehow refresh the page and show the actual content. The question is: how should the refresh be triggered?

This might be better as a separate feature request, but I wonder if it's worth generalising this: in next.config.js specify a list of error types for which the name (and no other properties) are exposed to an error boundary:

module.exports = {
 exposeErrorNames: ["ForbiddenError"],
};

"use client";
export default function Error({
 error,
 reset,
}: {
 error: Error & { digest?: string }
 reset: () => void
}) {
 if (error.name === "ForbiddenError") {
 // render forbidden UI
 }
 // render internal server error UI
}

I think this is an important use case, especially because Next.js advocates pushing auth logic into the data layer, as accessibleBy does in your example.

Referring to the error by class name might be too fragile though. What if different libraries use error classes with the same name? Or what if an error class is renamed?

I think what we want is to abstract the try / catch in your first post. I wonder if the proposed request interceptors could help? There was a suggestion for interceptors to accept an argument that wraps the rendering process. So perhaps your example could be handled with something like:

export default async function intercept(request: NextRequest, complete: Thenable<void>) {
 try {
 await complete;
 } catch (e) {
 if (e instanceof ForbiddenError) {
 notFound();
 }
 throw e;
 }
}

forbidden() will be like notFound(), which has the never return type. Behind the scenes, it throws a special object that Next.js knows to catch and handle.

I understand that's how it works under the hood, I'm talking purely from a DX perspective, I'm expecting some terminating thing to appear in the code (either a return or a throw)

You can return forbidden(); if you want, same as you can return notFound(); - it won't do anything