如何协调Firebase身份验证令牌刷新与服务器端呈现

我们正在工作的Next.js应用程序中使用Firebase。我对这两个都不熟悉，但我尽了最大的努力去了解它们。我的问题更多的是Firebase，而不是Next.js。以下是上下文：

• 在客户端应用程序中，我对我们的API进行了一些调用，在

  授权

  头中传递了一个JWT（ID令牌）。API调用

  admin.auth（）.verifyIdToken

  检查ID标记是否足够新鲜。这很好，因为我或多或少地保证ID令牌会定期刷新（通过使用

  onIDTokenChanged

  （）

• 现在，我希望能够在服务器端呈现我的应用程序页面。为了做到这一点，我将ID令牌存储在服务器可读的cookie中。但从现在开始，我无法保证用户下次通过完整页面加载应用程序时，ID令牌是否足够新鲜

我找不到与onIDTokenChanged等效的服务器端

这提到了一个刷新令牌的方法。我可以从服务器上点击它并给它一个刷新令牌，但感觉我完全脱离了Firebase领域，我担心维护一个临时系统将是一个负担

所以我的问题是，人们通常如何协调Firebase auth和SSR？我是否遗漏了什么

---

谢谢！

我最近也遇到了同样的问题，我自己解决了。我创建了一个非常简单的页面，负责强制firebase令牌刷新，并将用户重定向回请求的页面。如下所示：

• 在服务器端，从Cookie中提取令牌

  exp

  值后检查其是否存在（如果您在该服务器上使用firebase admin，则在验证后可能会将其作为错误告知您）

//可以是这样的处理程序
const handleTokenCookie=（上下文）=>{
试一试{
const token=parseTokenFromCookie（context.req.headers.cookie）
等待验证令牌（令牌）
}捕捉（错误）{
如果（err.name=='TokenExpired'）{
//如果过期，用户将被重定向到/刷新页面，这将强制客户端
//令牌刷新，然后将用户重定向回所需页面
const encodedPath=encodeURIComponent（context.req.url）
上下文。书面材料（302{
//注意，编码避免了URI问题，“req.url”也将
//保持所有查询参数不变
位置：`/refresh？重定向=${encodedPath}`
})
context.res.end（）
}否则{
//其他授权错误。。。
}
}
}

此处理程序可以在/页上使用，如下所示

///pages/any-page.js
导出异步函数getServerSideProps（上下文）{
const token=wait handleTokenCookie（上下文）
如果（！令牌）{
//令牌无效！正在将用户重定向到/刷新页面
返回{}
}
//你的代码。。。
}

• 现在您需要创建一个简单的

  /refresh

  页面，负责在客户端强制firebase令牌刷新，并且在令牌和cookie都更新之后，它应该将用户重定向回所需页面

///pages/refresh.js
常数刷新=（）=>{
//这个钩子有点像https://github.com/vercel/next.js/blob/canary/examples/with-firebase-authentication/utils/auth/useUser.js
const{user}=useUser（）
React.useffect（函数forceTokenRefresh（）{
//您还应该处理当前用户仍在加载的情况
当前用户
.getIdToken（true）//true将强制刷新令牌
.然后（（）=>{
//更新用户cookie
setUserCookie（当前用户）
//重定向回原来的位置
const decodedPath=window.decodeURIComponent（Router.query.redirect）
路由器.替换（解码路径）
})
.catch（（）=>{
//如果刷新时发生任何错误，请重定向到主页
路由器。替换（“/”）
})
}，[currentUser]）
返回(
//刷新令牌时显示简单加载？
)
}
导出默认刷新

---

当然，如果令牌过期，它会延迟用户的第一个请求，但它可以确保令牌有效，而不会强迫用户再次登录。

服务器不应该尝试为用户刷新ID令牌。这是客户端应该执行的操作，然后将更新的ID令牌传递给服务器。相反，服务器应该只刷新ID令牌验证它从客户端获得的ID令牌（通常在

授权

头中传递，但在cookie中也可以工作）。为什么您发现自己想要在服务器上刷新ID令牌？感谢您的回复。我发现自己想要在服务器上刷新的原因是，如果没有这一潜在步骤，我无法在服务器上呈现特定于用户的内容，这对我来说是一种困扰。我知道您需要在服务器上拥有ID令牌才能安全地查找该用户的内容，但我仍然不理解您为什么必须刷新它。当您处理该用户的单个请求时，令牌过期的可能性极低。当您收到来自同一用户的另一个请求时，该请求应再次包含其ID令牌。Firebase自己的服务就是这样处理的在这种情况下。让我们看看我是否可以更好地解释：-用户登录FB。我的客户端应用程序接收ID令牌和刷新令牌。我将ID令牌存储到cookie中-用户重新加载页面，服务器获取cookie，该cookie仍有大约一个小时的生存时间。-用户关闭浏览器并离开-3天后，用户返回并加载站点。如果服务器仍然有cookie，则令牌已过期，这是我的问题。我可以给cookie一个小时的生存期，但下次用户返回时，他们将注销。是否无法保证登录的SSR长期有效？这是一种有趣的方法，感谢您的贡献。在工作中，我们正在考虑rolling输出或拥有可以更长的令牌-l