[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.
-
背景
在 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