警告
首先,您应该评估是否需要客户端重定向(在 React 内)、服务器端重定向(301 HTTP 响应)或服务器端重定向 + 身份验证(301 HTTP 响应,但还要检查一些逻辑身份验证)。
这是我能写的最完整的答案。但是,在大多数情况下,您不需要任何这些。就像在任何 React 应用程序中一样重定向。 首选客户端重定向。只需使用useEffect + router.push,就是这样。
服务器端重定向很诱人,尤其是当您想要“保护”私人页面时,但您应该评估您是否真的需要它们。通常,你不会。它们会引发意想不到的复杂性,例如管理身份验证令牌和刷新令牌。相反,您可能希望在架构中添加网关服务器、反向代理或任何前端服务器,以处理此类检查。
请记住,Next.js 只是 React 应用程序,使用 Next.js 高级功能(如 SSR)需要付出一定的代价,在您的上下文中应该是合理的。
下一个 9.4 答案
您好,这是一个适用于所有场景的示例组件:
Vulcan next starter withPrivate access
Example usage here
答案很庞大,如果我以某种方式违反了 SO 规则,很抱歉,但我不想粘贴 180 行代码。如果您想同时支持 SSR 和静态导出,则 Next 中没有简单的模式来处理重定向。
以下场景都需要特定的模式:
- 服务器端渲染:如果允许,我们会渲染页面,如果不允许,我们会进行 HTTP 重定向
- 静态渲染(服务器端):我们什么都不渲染,但我们仍然将页面包含在构建中
- 客户端渲染,静态导出后:我们检查客户端是否用户是auth,是否重定向。在此检查期间或如果我们正在重定向,我们不会显示任何内容(或加载程序)。
- 客户端使用 next/router 重定向后的客户端渲染:相同的行为。
- SSR 后的客户端渲染:我们使用 getInitialProps 传递的道具来判断用户是否被允许,直接在第一次渲染时。只是快一点,避免出现空白闪光。
在撰写本文时(Next 9.4),您必须使用getInitialProps,而不是getServerSideProps,否则您将失去使用next export 的能力。
下一个 9.5 更新
正如@Arthur 在 cmets 中所述,9.5 还包括设置redirects in next.config.js 的可能性。
我还不清楚这个功能的局限性,但它们似乎是全局重定向,例如当您需要移动页面或仅在有限的时间内允许访问时。
因此,它们并不意味着例如处理身份验证,因为它们似乎无权访问请求上下文。再次,有待确认。
下 10 个新文档更新
此解决方案特定于根据身份验证的重定向。
Authentication patterns are now documented
我不喜欢从getServerSideProps 进行身份验证,因为在我看来太晚了,并且很难使用高级模式(例如处理刷新令牌)进行设置。但这是官方的解决方案。
您可能还想根据 Vercel 仪表板的工作方式(在撰写本文时)检查记录的 in this ticket 方法,以防止未经身份验证的内容闪现
下一个 10.2 标头和基于 cookie 的重写更新
Next 10.2 引入了基于标头和 cookie 的 Rewrites。
这是重定向服务器端的好方法,基于身份验证 cookie 或标头的存在。
但是,请记住,这不是安全重定向。用户可以使用虚假令牌更改其请求标头。您仍然需要网关、反向代理或前端服务器来实际检查令牌有效性并正确设置标头。
编辑:注意网址不会改变。重写将 URL 指向应用程序的现有页面,而不更改 URL => 它允许您拥有“虚拟”URL。
示例用例:假设您有一个已翻译的页面src/contact.tsx,并设置了 i18n 重定向。您可以通过将/de/kontact 重写为/de/contact 来翻译页面名称本身(“联系人”)。
下一个 12 更新
现在middlewares 让您可以完全控制服务器端重定向。
但是,请再次记住,大多数情况下,客户端重定向和检查就足够了。
旧答案(有效,但静态渲染会混乱)
半官方示例
with-cookie-auth 示例重定向到 getInitialProps。我不确定它是否是一个有效的模式,但这里是代码:
Profile.getInitialProps = async ctx => {
const { token } = nextCookie(ctx)
const apiUrl = getHost(ctx.req) + '/api/profile'
const redirectOnError = () =>
typeof window !== 'undefined'
? Router.push('/login')
: ctx.res.writeHead(302, { Location: '/login' }).end()
try {
const response = await fetch(apiUrl, {
credentials: 'include',
headers: {
Authorization: JSON.stringify({ token }),
},
})
if (response.ok) {
const js = await response.json()
console.log('js', js)
return js
} else {
// https://github.com/developit/unfetch#caveats
return await redirectOnError()
}
} catch (error) {
// Implementation or Network error
return redirectOnError()
}
}
它同时处理服务器端和客户端。 fetch 调用是实际获取身份验证令牌的调用,您可能希望将其封装到单独的函数中。
我会建议什么
1. 在服务器端渲染上重定向(避免在 SSR 期间闪烁)
这是最常见的情况。此时您需要重定向以避免初始页面在首次加载时闪烁。
MyApp.getInitialProps = async appContext => {
const currentUser = await getCurrentUser(); // define this beforehand
const appProps = await App.getInitialProps(appContext);
// check that we are in SSR mode (NOT static and NOT client-side)
if (typeof window === "undefined" && appContext.ctx.res.writeHead) {
if (!currentUser && !isPublicRoute(appContext.router.pathname)) {
appContext.ctx.res.writeHead(302, { Location: "/account/login" });
appContext.ctx.res.end();
}
}
return { ...appProps, currentUser };
};
2. 在 componentDidMount 中重定向(在禁用 SSR 时有用,例如在静态模式下)
这是客户端渲染的后备。
componentDidMount() {
const { currentUser, router } = this.props;
if (!currentUser && !isPublicRoute(router.pathname)) {
Router.push("/account/login");
}
}
我无法避免在静态模式下闪烁初始页面添加这一点,因为您无法在静态构建期间重定向,但它似乎比通常的方法更好。随着我的进步,我会尝试编辑。
Full example is here
Relevant issue, which sadly ends up with a client only answer
New issue I've opened regarding redirecton