V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lcq
V2EX  ›  Java

微服务系统中,分别有后台系统管理员和 APP 用户两种类型的用户,该如何做认证?

  •  
  •   lcq · 2020-08-18 15:19:34 +08:00 · 3427 次点击
    这是一个创建于 1593 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题,是把他们认为都是用户整合在一个表里还是应该做两套认证,求各位大佬给个建议
    23 条回复    2021-09-13 11:19:30 +08:00
    kop1989
        1
    kop1989  
       2020-08-18 15:23:04 +08:00
    都可以。
    但理论上讲分表更好。
    因为很有可能面向管理人员和面向 c 端的登录不是一个服务。( c 端和 b 端隔离)。
    ffLoveJava
        2
    ffLoveJava  
       2020-08-18 15:38:05 +08:00
    我更想知道权限怎么控制 ? 例如 PC 端有一套操作权限(菜单、页面、按钮) ,APP 有一套权限(页面、按钮)。那怎么分贝控制权限?
    @kop1989 @lcq
    securityCoding
        3
    securityCoding  
       2020-08-18 15:42:22 +08:00
    我个人理解是不用分表, 可以独立出几张不同的认证源表
    t_user, t_user_oauth_pw, t_user_oauth_wechat, t_user_oauth_qq, t_user_login_flow
    用户表(公共属性:uid,类型等等)
    认证表-用户名密码
    认证表-微信登录
    认证表-qq 登录

    专门的账户服务,提供不同方式的登录 api
    BUserLoginByPw();
    CUserLoginByWechat();

    网关: 登录态验证收拢到网关统一处理,业务微服务不用管登录态,直接从上下文获取相关的用户属性就行了
    securityCoding
        4
    securityCoding  
       2020-08-18 15:45:08 +08:00
    @ffLoveJava 权限资源的管理模型就是 rbac, 账户创建的时候会结合业务同步初始化权限资源 , 登录后前端直接查询菜单 api 渲染即可
    lcq
        5
    lcq  
    OP
       2020-08-18 15:46:33 +08:00
    @kop1989 是的,这两个是不同的服务,只是都用到了 oauth2.0 授权机制,如果分表,app 已经认证的用户怎么杜绝使用 token 去请求管理后台的接口,网关校验吗? 然后 c 端和 b 端具体怎么做到隔离,微服务小白,求大佬支招
    lcq
        6
    lcq  
    OP
       2020-08-18 15:51:11 +08:00
    @securityCoding 谢谢 有考虑过用这种方式,按我现在的系统就是一个用户公共表 一个 APP 用户表 一个管理系统用户表,公共表中区分用户类型这样吗
    lcq
        7
    lcq  
    OP
       2020-08-18 15:52:15 +08:00
    @ffLoveJava 可以再登录的时候初始化用户操作权限
    damai0419
        8
    damai0419  
       2020-08-18 15:53:11 +08:00
    应该有一张统一的用户表,收拢后台系统系统和前台系统的公共属性,例如账号,密码,性别等。然后再分出来两张表,后台员工表和 app 用户表,分别存储差异化信息。
    damai0419
        9
    damai0419  
       2020-08-18 15:55:44 +08:00
    @damai0419 登陆在网关统一处理,鉴权的话就分两套逻辑处理。
    luvroot
        10
    luvroot  
       2020-08-18 15:58:21 +08:00
    RBA jwt
    securityCoding
        11
    securityCoding  
       2020-08-18 16:00:08 +08:00
    @lcq 是这样的,同一个领域对象的数据不要强行分割
    securityCoding
        12
    securityCoding  
       2020-08-18 16:01:01 +08:00
    @lcq token 校验肯定是不同的,网关根据不同的校验配置去请求相应的认证接口
    lcq
        13
    lcq  
    OP
       2020-08-18 16:03:53 +08:00
    @damai0419 然后如何避免一个已经认证的用户携带 token 请求另一个系统的接口,是在网关做检验吗
    lcq
        14
    lcq  
    OP
       2020-08-18 16:07:01 +08:00
    @securityCoding 好的 get 到了 谢谢
    chinvo
        15
    chinvo  
       2020-08-18 16:09:47 +08:00
    @securityCoding #3 理论上更科学的设计方法是 微信登录 的 openid 和 QQ 登录 的 userid 都属于 user token, 那么就都放到 user_tokens 表里面, 用一个字段区分 token 类型.

    用户表里放 用户名 /账号、手机号、邮箱、手机号验证状态、邮箱验证状态、密码、账号状态 等
    chinvo
        16
    chinvo  
       2020-08-18 16:11:03 +08:00
    然后有一个 user_profiles 表放普通用户的“profile”, 有个其他表放内部用户的 profile

    用 user_role 表放 多对多 的 用户 - 角色 关系

    具体业务系统里用 角色 或 权限 限制特定用户群
    securityCoding
        17
    securityCoding  
       2020-08-18 16:16:05 +08:00
    @chinvo 是的,对于相同认证类型可以放一张表,用户量大了还是推荐分表存储
    Hanggi
        18
    Hanggi  
       2020-08-18 16:16:32 +08:00
    嗯嗯,同意不分开用户,RBAC 控制权限,可以应付大部分情况。
    permission 部分使用 resource 和 operation (命名可能不同),区分用户操作权限是后台还是 APP 。
    把 permission 分配给相应的 Role,再把 Role 分配给用户就好了。
    gz911122
        19
    gz911122  
       2020-08-18 16:44:18 +08:00
    两套比较好.
    一个是面向公司内部人员的. 一个是面向用户的.
    二者基本没啥关联的.
    h123123h
        20
    h123123h  
       2020-08-18 16:54:56 +08:00 via iPhone
    做两套
    chihiro2014
        21
    chihiro2014  
       2020-08-18 17:12:56 +08:00
    做两套更好,处理起来也简单
    jeffh
        22
    jeffh  
       2020-08-18 18:34:45 +08:00
    这是两种不同用户,最好两套表,app 面向用户可能会保存地址等信息,admin 面向后台用户,可能有岗位的信息。同时 admin 也有权限的控制。不能认为这两种用户是一样的。
    devswork
        23
    devswork  
       2021-09-13 11:19:30 +08:00
    我也遇到这个问题了,来看下大家意见
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1632 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 16:48 · PVG 00:48 · LAX 08:48 · JFK 11:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.