通过Next-auth的JWT回调或会话回调来存储其他信息? (在下一个实施中保存Patreon Tier)
我试图与Patreon API一起使用Next-auth。登录&效果很好,但是我现在也想在某个地方保存用户层 - 问题在哪里?我当时想通过JWT回调将其直接放在JWT上,或者通过会话回调将其放在会话中。
我尝试将其添加到会话中,但似乎确实放慢了登录:
async session({ session, token, user }) {
session.access_token = token.access_token;
let tier = await getUserTier({ access_token: token.access_token });
session.tier = tier;
return session;
}
每当会议回调被调用时,它也会效率低下获取这些数据 - 似乎很多。有什么方法可以加快检查层的过程?我可以在哪里保存层的惯例吗?
I am trying to use next-auth with the patreon api. Logging in & out works fine, but I now want to also save the users tier somewhere - the question is where? I was thinking of putting it directly on the jwt via the jwt callback, or maybe in the session via the session callback.
I have tried adding it to the session, but it seems to really slow down login:
async session({ session, token, user }) {
session.access_token = token.access_token;
let tier = await getUserTier({ access_token: token.access_token });
session.tier = tier;
return session;
}
It also feels inefficient fetching this data every single time the session callback is called - which seems to be a lot. Is there any way to speed up this process of checking the tier? Is there any convention over where I could save the tier?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
它自然而然地减慢了流程,因为默认情况下是必不可少的网络流量,您必须等待getUsertier请求。
我认为您有2个选项:
直接将用户层直接保存在数据库的用户表中,然后您应该可以通过一个回调参数访问它。
根本不包括会话中的层,而是在您真正需要的时候仅在客户端代码中获取它。
我想我会选择第二个选项,因为实际上不需要在会话中包含此信息。如果您的论点是需要在应用程序中到处都需要这些信息,您仍然可以在中心的某个地方执行请求 - 例如布局组件 - 然后通过 redux Store 或类似(取决于您在应用中使用的内容)
Its slowing down the process naturally because, additionaly to the network traffic that is neccesary by default, you have to wait for your getUserTier request.
I think you have 2 options:
Saving the user Tier in the User table of the database directly, then you should have access to it through one of the callback parameters.
Not include the tier in the session at all, but fetching it in your client code only at the time you really need it.
I think i would go with the second option because there is no real need to include this information in the session. If your argument is that need that information everywhere in your app, you can still do the request somewhere central - like in a Layout component - and then provide the info via Context or Redux Store or similar(depends on what you use in your app already)