Return redirect from getServerSideProps

[messa]

For example to redirect from / to /dashboard if user is logged in, otherwise to /login.

• When the getServerSideProps is called during SSR it should return a 3xx response with Location header.
• When the getServerSideProps is called during client-side router transition it should perform Router.push().

Would be cool to be able to do this easily, for example by return { redirect: '/login' }.

Or is it possible to do such thing now? I could not find any way except maybe handling both cases manually and doing Router.push() myself in the page component.

[fabb]

Would be nice. In the mean time we use a custom server.ts and have a redirect middleware there.

[patricebeutler]

Have you solved the redirect on client-side navigation? It seems to me that just returning a redirect from the getServerSideProps-request isn't enough when navigating on client-side?

Thanks!

[fabb]

Client side routing wouldn't get redirected, that's correct. In our case we can ignore the client side routing part, because we need the redirects just for SEO which does no client side navigation anyways. But it's true that we need to use only valid urls inside our next.js app. We use helper methods instead of the router directly, and transform paths there too, but mostly cutting away trailing slashes which next.js does not like.

[patricebeutler]

Thank you for the excellent clarification!

[aralroca]

I'm also interested in the answer! It's something that with getInitialProps is handled well, but I dunno how to do that with the new getServerSideProps. However, probably the best option is to just do the navigation in the browser to the final route...

[adrianthedev]

If you want to redirect and set a status code you can use

res.writeHead(301, { Location: '/' })
res.end()

I created a method to call every time I need to filter out the requests and reused it in getServerSideProps.
Full example 👇

// somewhere in my app 
export const redirectIfUnauthenticated = async (context) => {
  const session = await getSession(context)

  if (!session) {
    const { res } = context

    res.writeHead(301, { Location: '/' })
    res.end()
   
    return true
  }
}

// I use this in all my page components where I want to authenticate.
export async function getServerSideProps(context: NextPageContext) {
  return await redirectIfUnauthenticated(context) || {
    props: {
      session: await getSession(context),
    },
  }
}

Later edit:

Actually, this 👆 doesn't really help that much. The browser will cache the 301 and that's not what's desired.

[timneutkens]

You can return redirect nowadays: https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

[adrianthedev]

Thank you for that 👆 🙏

[limdauto]

@timneutkens Can we set headers on a redirect return value in getServerSideProps? Actually, found it: #14890 (reply in thread) -- works like a charm!!

[rosshabe]

This worked for me thanks

[samstr]

Just encountered this myself today. +1 for supporting redirects that get handled on the server and client

[perryraskin]

This would be super helpful to be able to do. I too need to redirect a non-logged-in user from /dashboard to /login, or a logged-in user from / to /dashboard. Any quick workaround would be appreciated :)

[patricebeutler]

I think a more generic solution could be beneficial. In the code below, you can see how the next-routes package solves routing (note that this package has over 2k stars). Simply returning a redirect-url from getServerSideProps and handling the rest internally would‘t be compatible. In addition, some control over the http-status-codes returned for SSR-calls would be nice!

getRouter (Router) {
    const wrap = method => (route, params, options) => {
      const {byName, urls: {as, href}} = this.findAndGetUrls(route, params)
      return Router[method](href, as, byName ? options : params)
    }

    Router.pushRoute = wrap('push')
    Router.replaceRoute = wrap('replace')
    Router.prefetchRoute = wrap('prefetch')
    return Router
} 

A possible solution could be an async getServerSidePropsReceived(props, ctx) function or something in this direction. It would get executed both on the server and on the client.

For example, the developer sets a prop in getServerSideProps, let‘s call it redirectUrl for the moment. In the getServerSidePropsReceived function, the developer then can react to the redirectUrl-prop accordingly. Depending on the presence of ctx, the request could get ended with a status-code and a location-url (on SSR) or the route could get manipulated by using Router.replace() (on the client).

This would provide a lot of flexibility to the developer.

[samstr]

I'm doing this for now. See below.

Visiting /current-season should redirect you to /seasons/22/matches through both:

• client side navigation using next Router
• direct requests to the page (server).

When it's client-side routing the request to getServerSideProps contains a ctx.req.headers.referer string. So I'm using that to decide how we handle the redirect.

Warning: This was edited for the sake of the example so there might be a couple of syntax problems.

pages/current-season.js - this page should redirect to the current season

import { browserRedirect, serverRedirect } from 'utils/redirects';

const redirect = {
  href: '/seasons/[season]/matches',
  asPath: `/seasons/22/matches`,
  permanent: false,
};

export default browserRedirect(redirect);
export const getServerSideProps = async (ctx) => serverRedirect(ctx, redirect);

utils/redirects.js

import Router from 'next/router';
import React, { Component } from 'react';

export const browserRedirect = (redirect) => {
  return class Redirect extends Component {
    componentDidMount() {
      const { href, asPath } = redirect;
      Router.push(href, asPath); // Router.replace might be better here? not sure
    }

    render() {
      return <p>Redirecting...</p>;
    }
  };
};

export const serverRedirect = (ctx, redirect) => {
  const { referer } = ctx.req.headers; // if there's no referer then it was a server request
  const { asPath, permanent, external } = redirect;

  if (!referer || external) {
    res.setHeader('Location', asPath);
    res.statusCode = permanent ? 301 : 307;
  }

   return { props: {} };
};

Might have to tweak that slightly for your use-case but you get the idea.
Also let me know if there are any problems with this method. I would love to get an official implementation for redirects on both client and server.

[ingoclaro]

use ctx.res, you can also do:

ctx.res.writeHeader(307, { Location: asPath })
ctx.res.end()

[daveteu]

res is undefined

this doesn't work for you?

    export async function getServerSideProps({req, res, query}) {

    res.writeHead(302, { Location: '/404' }.   <-- Remember to use 30X codes even if 404, 404 doesn't redirect

   }

[karlhorky]

Ah, I guess the RFC by Tim is the way to go for the future: #14890

[marceloschreiber]

@samstr thank you!

doing the ctx.req.headers.referer verification did the trick to avoid the error

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

This was the best workaround I could find while waiting for #14890.

[bcomnes]

Same, thank you for this tip! Helped a lot.

[elderapo]

What about something like this:

import { NextPageContext } from "next";
import Router from "next/router";

export type NextRedirectOptions = {
  to: string;
  ctx: NextPageContext;
};

export const nextRedirect = async (options: NextRedirectOptions): Promise<any> => {
 if (typeof window === "undefined") {
    options.ctx.res.writeHead(307, { Location: options.to });
    options.ctx.res.end();
  } else {
    Router.replace(options.to);
  }

  return new Promise(() => {});
};

and

TestPage.getInitialProps = async ctx => {
  const isAuthenticated = true/false;

  if (!isAuthenticated) {
    return nextRedirect({ ctx, to: "/login" });
  }

  const data = await fetchStuff();

  return data;
};

This way our component won't get rendered if we redirect in getInitialProps. The only downside I can think of is promise returned in nextRedirect might potentially cause a memory leak - gotta check that though.

[justincy]

That's using getInitialProps. This discussion is about redirects with getServerSideProps.

[lipp]

It would be nice, if returning 30X redirect status codes from getServerSideProps would be respected by Next.js`s router.

[justincy]

I bet that would actually be pretty easy by modifying this fetch call in the router to not automatically follow redirects by adding the option redirect:'manual'. I might try doing that next week.

[justincy]

I managed to get it working. Turns out the router isn't setup to handle this well. In it's current state, it'd be much better to follow the original recommendation of handling return { redirect: '/login' }.

[justincy]

The with-iron-session and auth0 examples have been updated to do redirects from within getServerSideProps().

I'm not convinced that this is the best pattern. If you watch the network traffic, the browser follows the redirect and requests the page, but it was an AJAX request so the URL doesn't change. It just seems like Next is smart enough to figure out what's going on and makes another request for the page that the AJAX request was redirected to. It's very inefficient and perhaps only works due more to happenstance than intent. But I'm still learning.

[justincy]

It looks like returning a redirect actually causes the page to do a full reload which again triggers a redirect only this time it's from the browser's initial page load request so the browser honors the redirect and the user ends up at the final intended location. Though again, that's all accomplished very inefficiently.

[justincy]

I figured out how this works. The browser follows the redirect from the AJAX request, then Next attempts to parse a JSON response which throws an error because it actually received HTML:

SyntaxError: Unexpected token < in JSON at position 0

In response to the error, Next triggers a full page reload. This time the redirect works as expected because it's in response to a page load: the browser follows the redirect and renders the HTML as expected.

We need a better way.

[justincy]

I submitted a PR to add the redirect functionality proposed in the initial post:

export async function getServerSideProps() {
  return {
    props: {},
    redirect: '/',
  }
}

[rjyo]

I found adding the custom _error page can solve this:

When a redirect is needed, just throw a redirect error. By this means you don't need to include additional props for the component.

export const getServerSideProps: GetServerSideProps = async () => {
  ...
  if (data === null) throw new RedirectError(302, '/')
  ...
}

in my _error.tsx

ErrorPage.getInitialProps = async function ({ res, err }) {
  const props = { statusCode: 500 }
  if (!res) return props

  if (err instanceof PageError) {
    props.statusCode = err.statusCode
    res.statusCode = err.statusCode
    if (err instanceof RedirectError) {
      res.writeHead(err.statusCode, { Location: encodeURI(err.url) })
      res.end()
    }
  } else {
    console.error(err)
  }
  return props
}

And I have 2 types of error

export class PageError extends Error {
  statusCode = 500
}

export class NotFoundError extends PageError {
  statusCode = 404
}

export class RedirectError extends PageError {
  url: string

  constructor(code: number, url: string) {
    super()
    this.statusCode = code
    this.url = url
  }
}

[justincy]

It looks like that will only work for server-side requests. Is that right? Have you tested it with client-side requests? Redirects are done differently client-side.

[justincy]

BTW, that's a clever solution.

[rjyo]

Thanks! I'm working on a pure SSR stack.

I guess the code in getInitialProps in the _error page needs some tweak for the client, as the res shall be empty.

[larbisahli]

@rjyo If possible can you plz share that repo I like the way you handled the error in ssr.

[lilrogalski]

I ended up using this solution to show an error page when a user tries to access a blog post that doesn't exist. It's not pretty but it gets the job done for now:

export async function getServerSideProps(ctx: NextPageContext) {
  // get article data from contentful
  const { article } = ctx.query
  const post = await contentful.fetchNewsPostBySlug(article)

  // if no post is found, set error prop and show error page
  if (!post) {
    const props = {
      error: true,
    }

    return {
      props,
    }
  }

  // code to return article props if they exist
}

// in my component:
interface Props {
  post: PostData
  error?: boolean
}

export default function NewsArticlePage({ post, error }: Props) {
  if (error) {
    return <ErrorPage />
  }
 
  // code to return page component if post data exists
}

[justincy]

That's a good pattern to use until Next.js has built-in support for this. You could improve your code by making a withError HOC if you wanted to avoid directly handling the error in each page.

[onderonur]

I think this is the best solution for now. You can even create wrapper functions. One HOC for your page with server-side props, and one higher-order function for getServerSideProps. Something like:

interface ServerSideError {
  statusCode: number;
  message: string;
}

type WithServerSideData<Data, P = {}> = P & {
  initialData?: Maybe<Data>;
  error?: Maybe<ServerSideError>;
};

function withGetServerSideError<P, Q>(
  getServerSideFn: GetServerSideProps<P, Q>,
) {
  return async function wrappedGetServerSideProps(
    ctx: GetServerSidePropsContext<Q>,
  ) {
    try {
      const result = await getServerSideFn(ctx);
      return result;
    } catch (err) {
      const error: ServerSideError = {
        statusCode: err.statusCode,
        message: err.message,
      };
      return { props: { error } };
    }
  };
}

// eslint-disable-next-line @typescript-eslint/no-explicit-any
function withError<P extends WithServerSideData<any>>(Page: NextPage<P>) {
  return function WrappedPage(props: P) {
    const { error } = props;
    if (error) {
      return (
        <ErrorPage statusCode={error.statusCode} message={error.message} />
      );
    }

    return <Page {...props} />;
  };
}

And then use it just like:

function getServerSidePropsFn(ctx){
    // ...
}

export const getServerSideProps = withGetServerSideError(getServerSidePropsFn);
export default withError(NewsArticlePage);

[timneutkens]

Opened a RFC here: #14890

[samrith-s]

Quick question: Handling any kind of private routes etc, will result in us losing ASO?

[timneutkens]

ASO?

[samrith-s]

Sorry, Automatic Static Optimization.

[timneutkens]

The redirecting does not affect the automatic static optimization, using getServerSideProps does though.

[mylastore]

So what is the solution for redirecting on both server and client using getServerSideProps that woks correctly.

Any luck on this?

[emindeniz99]

You can check the other topic #14890 (comment)

[irwansyafani]

For Short ✨🚀

I've got example of Next Docs: 🔗 link

you have to put code below inside your getServerSideProps

return {
  redirect: {
    destination: '/',
    permanent: false,
  },
}

It works for me, hopefully it would help 💯✨

[artrozo]

@irwansyafani This helped, I feel this is the right implementation

[jonathanmv]

Your link seems to be broken. I think it was moved here

[magicDvlp]

Can I get the props after redirection?

return {
  redirect: {
    destination: '/auth-page',
    permanent: false,
  },
  props: {
    initialReduxState: {user},
  }
}

After the redirect, I am trying to get the props on the "auth-page". The props object is empty.

[700software]

not possible because a new request would be issued after redirect. You need either session management e.g. cookie based or else you need to add query string parameters and use that for the auth-page in lieu of props.

The more you understand the actual HTTP requests the browser issues due to redirect the better you will understand why that is not possible as you have written.

[codedbychavez]

Take a look at: https://nextjs.org/docs/api-reference/data-fetching/get-server-side-props#redirect

export async function getServerSideProps(context) {
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  if (!data) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
      },
    }
  }

  return {
    props: {}, // will be passed to the page component as props
  }
}

[deniapps]

It works from SSR but does not work when calling getServerSideProps() from the client side.
For example: the page https://example.com/a is redirected to https://example.com/b
And then on the page https://example.com/c, we use:

<Link href="/a">A</Link>
```
After clicking on it, it will not redirect to https://example.com/b. 

[hofewo]

getServerSideProps() is not called anymore by default when you use NextJS' Link. To call getServerSideProps again in your example (and enable the redirect to page B), you need to set a shallow = false attribute in your Link.

[deniapps]

Thanks! But shallow is default to false, so it's not the issue.

Actually, I figured out that it was due to the cache of old logic.
I used to have the following code in getServerSideProps, which does not work unless SSR:

const { res } = context;
res.writeHead(301, { location: "/redirect-to-url" });
res.end();

With the new code:

return {
      redirect: {
        destination: '/redirect-to-url',
        permanent: false,
      },
 }

It works as expected, and my only issue is related to the caching problem.