[RFC] 040 - 用户鉴权 #2022
Replies: 4 comments 7 replies
-
|
其实两种方案，都需要自己实现鉴权？ 就是说控制用户对某个功能（URL）的访问这样。 |
Beta Was this translation helpful? Give feedback.
-
|
还有就是 nextauth 的 token 离线刷新也是要自己实现的，而且是每个 sso provider 都要实现一次。 |
Beta Was this translation helpful? Give feedback.
-
|
@cy948 这个有实现示例吗？有的话其实可以让大家分头做下 |
Beta Was this translation helpful? Give feedback.
-
|
这个功能的需求背景是：团队需要禁用某个成员的账号（ban user）。而实现该需求的方法有：
综上，token 离线刷新不是必要实现的，若能实现数据库管理 session，即为 next-auth 接入数据库（如使用 prisma adapter 作为database adapter 接入 supabase这样的pgsql）也能实现“ban user”功能。 |
Beta Was this translation helpful? Give feedback.
-
我理解现在的 middleware 里应该已经支持了从 SSO Provider 读 token，应该也能做这个校验的吧？是需要什么额外的处理逻辑不？ |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
目前看到一篇非常契合我们诉求的文章： https://neon.tech/blog/nextjs-authentication-using-clerk-drizzle-orm-and-neon 这篇文章基于 clerk、drizzle 和 neon 来实现整个鉴权逻辑，在我们的场景下，neon 和 supabase 基本上可以互相替代，因此参考性很够。 它的项目：https://github.com/evanshortiss/neon-clerk-drizzle-nextjs |
Beta Was this translation helpful? Give feedback.
-
GlobalStore 剥离 UserStore在 0.x 时代，由于我们没有用户体系，应用的设置等价于全局设置。但是在有了用户体系后，用户的设置和应用的设置就有了区分度，因此 需要将 GlobalStore 中的部分信息剥离到 UserStore 中。 同时，由于现在 GlobalStore 中也存在存放 serverConfig ，用于判断某些页面是否显隐的场景，其的作用和 featureFlags 很类似，因此将需要率先重构，将所有用到 globalStore 的 serverConfig 判断状态的场景均迁移到 featureFlagsStore 中，并将其重命名为 ServerConfigStore。 PR： #2263 然后将 globalStore 重命名为 userStore，并将其中common部分再重新剥离出来，变成 globalStore 。PR： #2264 UserStore Auth Slice 接入用户鉴权的重头戏是 auth 相关的实现，在 #2214 中将会统一抽象一个 auth slice，用于承载用户鉴权相关的服务/方法。 由于我们计划接入的 clerk ，与 next-auth 是两个不同的方案，其使用的 provider ，和对应的 react hooks 都不一样，这会导致未来在实现时需要做条件判断，这不是我们所期望的。 所以 Auth slice 的目的也是将这部分的实现收进来，在应用层消费时无需感知背后的鉴权方案，直接使用 const avatar = useUserStore(userProfileSelectors.userAvatar);这样的取值方式即可拿到对应的数据进行展示。调用 登录/登出方法也只需从 userStore 中取值即可。 const login = useUserStore(s=>s.login);需要达成这样的效果，我们需要在鉴权 Provider 中实现 provider 侧的数据注入到 userStore 中。只要 store 能够拿到 provider 中的数据，那么下游消费 store 数据就可以无需感知 provider 是谁。 |
Beta Was this translation helpful? Give feedback.
-
按需嵌入 Provider首先是现有的 AuthProvider，集成上 clerk 后，它的状态如下： import { PropsWithChildren } from 'react';
import Clerk from './Clerk';
import NextAuth from './NextAuth';
const AuthProvider = ({ children }: PropsWithChildren) => {
if (ENABLED_CLERK) return <Clerk>{children}</Clerk>;
if (ENABLE_OAUTH_SSO) return <NextAuth>{children}</NextAuth>;
return children;
};
export default AuthProvider;单个 Provider 实现示例以 clerk 为例： 其中 import { ClerkProvider } from '@clerk/nextjs';
import UserUpdater from './UserUpdater';
const Clerk = ({ children }: PropsWithChildren) => {
return (
<ClerkProvider>
{children}
<UserUpdater />
</ClerkProvider>
);
};
export default Clerk;实现上述思想的核心工作在于 'use client';
import { useSession, useUser } from '@clerk/nextjs';
import { memo } from 'react';
import { createStoreUpdater } from 'zustand-utils';
import { useUserStore } from '@/store/user';
// update the user data into the context
const UserUpdater = memo(() => {
const { isLoaded, user, isSignedIn } = useUser();
const { session } = useSession();
const useStoreUpdater = createStoreUpdater(useUserStore);
const lobeUser = {
avatar: user?.imageUrl,
firstName: user?.firstName,
fullName: user?.fullName,
id: user?.id,
latestName: user?.lastName,
username: user?.username,
} as LobeUser;
useStoreUpdater('isLoaded', isLoaded);
useStoreUpdater('user', lobeUser);
useStoreUpdater('clerkUser', user);
useStoreUpdater('isSignedIn', isSignedIn);
useStoreUpdater('clerkSession', session);
return null;
});
export default UserUpdater;
useEffect(()=>{
useStore.setState( { [key]: value })
},[value])
通过上述 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
背景
在 LobeChat 0.x 时期，其实有很多用户提出了希望有用户体系 / 鉴权体系，这在面向 toB 场景的场景下会非常有用。
不过由于我们目前的定位主要面向 ToC 场景，因此在 0.x 中没有计划接入用户体系。而在社区成员先行尝试和贡献了基于
next-auth的 OAuth 方案，目前针对一些简单的团队内部使用场景也可堪一用。并且后续陆陆续续也支持了 AzureAD、Github、Authentik、ZITADEL 等其他 Providers 。不过，目前的方案相对来说并不完善，而在 1.0 中，我们计划实现相对完整的用户体系。
调研
next-auth+supabase Auth由于数据库选型基本上确定，我们即将推出的 LobeChat Cloud 可能会先使用 Supabase 作为整个数据库服务。同时之前也有看到 Supabase 有提供 Auth 的方案。我本来以为可以用 next-auth 的 supabase 的 adaptor 完成两者的接入，这样可以最大化复用 LobeChat 现有的
next-auth技术方案和 Supabase Auth 的体系化能力。但是通过详细查阅文档后发现两者还不太一样。
next-auth的 supabase 的 adaptor 相当于在数据库里建了个独立的表，然后走的还是 next-auth 这套。还不是supabase自己现成的方案。如果采用了这个 adaptor， Supabase 现成的 Auth 能力（例如邮箱服务、手机登录、二次验证）就都不可用了。因此这个方案被 pass 了。
直接接入 Supabase 的 Auth
然后我的第二个思路是要不就直接用 Supabase 的 Auth，但看了下文档好像全篇没看到用户界面的部分。同时看了下登录注册相关的逻辑，需要引入
Supabase的库然后加入相应的实现代码集成。个人觉得这不太符合我对 Auth 的集成使用预期。毕竟 Supabase 本质上还是数据库服务方，如果是无侵入式的完成整个 auth 流程，并落库，这样才是比较好的方式。所以上述这样耦合的代码方案我个人觉得并不符合我的预期。
所以进一步往下看到了 Clerk。
Clerk
Clerk 应该是近期开始火起来的 Auth 解决方案平台。我之前推上关注的一个设计师专门 show 过他给 clerk 做的方案，当时看过很惊艳。也有不少开发者有在推特上推荐了。看了下文档，基本上和
next-auth非常接近：套一个 provider、加一个中间件就能完成整个 auth 逻辑，上手很简单。同时整个设计风格就是之前推特上看到的那样，简约、现代。
因此后续的鉴权方案会考虑使用 clerk 而不是 Supabase。
设计思路
从最理想的情况来说，最好是我们自行基于 next-auth 实现完整一套的登录/注册/鉴权的UI和交互流程。但是这样一来相对成本会比较高。
所以考虑到实现成本，可能目前更倾向的方案是集成 clerk ，提供相对完整的一站式 Auth 能力。后续等有空了再在
next-auth基础上进一步做一个 Auth 方案。进展
Beta Was this translation helpful? Give feedback.
All reactions