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

同事说:正常情况下登录接口不返回用户信息,是这样吗

  •  
  •   lowett · 2023-09-25 13:15:54 +08:00 · 3984 次点击
    这是一个创建于 438 天前的主题,其中的信息可能已经有所发展或是发生改变。

    登录只是为了拿 token ,成功后要调用用户信息接口。

    经历过的项目都有返回用户信息,可能个人经历有局限,问下大家是怎样的

    craiet
        1
    craiet  
       2023-09-25 13:17:52 +08:00
    是的
    EEEEx
        2
    EEEEx  
       2023-09-25 13:18:08 +08:00
    返回啊, 然后也有用户信息接口
    MossFox
        3
    MossFox  
       2023-09-25 13:21:53 +08:00
    网页应用吗,如果 token 是存在本地的,登陆拿到 token 之后调用请求用户信息的接口可以确保 token 是被正确保存了的。
    如果使用的是 Cookie 存储 token ,在跨域 iframe 里面设置 Cookie 会失败。如果用其他方式的存储,用户如果禁用了 Cookie ,基本上所有 Storage API 都会在访问时抛出异常(包括 localStorage )。这些情况都算是,登陆请求成功但是 token 没有办法被保存的情境。

    我见过的大约只有上面这种了,楼下补充看看。
    chinagxwei
        4
    chinagxwei  
       2023-09-25 13:22:21 +08:00
    登录只返回登录账户信息,用户信息要单独获取
    k9982874
        5
    k9982874  
       2023-09-25 13:22:26 +08:00   ❤️ 2
    这玩意哪有什么规范,看情况,看心情。他就是懒。
    thinkershare
        6
    thinkershare  
       2023-09-25 13:25:30 +08:00
    看心情,也可也经用户基本信息放置到 token 里面,不过用户的 profile, 一般都是调用独立接口去获取到,比较认证和用户信息没那么强的关联性,特别实在 OAuth2 这种授权体系下。
    lowett
        7
    lowett  
    OP
       2023-09-25 13:26:03 +08:00
    项目是 app ,token 在 user 里面
    lambdaq
        8
    lambdaq  
       2023-09-25 13:26:22 +08:00
    > 正常情况下登录接口不返回用户信息

    很符合 RESTful 原教旨份子 给我的刻板印象。
    opengps
        9
    opengps  
       2023-09-25 13:26:44 +08:00
    这种设计没什么规定,因为用 token 可以去拿所有授权内的信息。
    可能为了方便,会多返回一个用户信息的 id 使用
    AoEiuV020JP
        10
    AoEiuV020JP  
       2023-09-25 13:28:19 +08:00
    有点坑,我们是登录返回一部分,但不够,还得调用户信息接口,
    ysy950803
        11
    ysy950803  
       2023-09-25 13:30:09 +08:00
    他想摸鱼,不想做,没什么所谓的规范和铁律。
    而且其实很多后端和前端的交互逼事儿,不是他写就是你写,后端写灵活性更大,反正就那么些接口调来调去。
    MeteorCat
        12
    MeteorCat  
       2023-09-25 13:32:26 +08:00 via Android
    玩家详情单独接口(用户详情记录大量最后充值时间最后充值金额小游戏签到这种,实际上登陆不需要这些),登陆只返回上次登陆时间 IP 简单信息
    Tink
        13
    Tink  
       2023-09-25 13:49:30 +08:00
    这不是看需求吗
    vikaptain
        14
    vikaptain  
       2023-09-25 13:50:10 +08:00
    我一般会顺带返回一些基本信息,像用户名,姓名这些。其他的更详细的信息就走详情接口
    yidinghe
        15
    yidinghe  
       2023-09-25 13:52:06 +08:00
    考虑到登录授权和用户信息属于不同的服务,请求两次是方便后端服务进行重构治理的,否则的话就等于是强行要求登录授权服务绑定用户信息服务。
    neptuno
        16
    neptuno  
       2023-09-25 13:57:28 +08:00
    大厂是这样的,小厂,就那么几个接口,登陆直接能返回,为啥还要再调用一次。
    sjn9588
        17
    sjn9588  
       2023-09-25 13:58:27 +08:00
    那打开 app 自动登录场景下,难道用来记住用户密码来做嘛?
    MeteorCat
        18
    MeteorCat  
       2023-09-25 14:02:00 +08:00 via Android
    登陆接口越简单越好,游戏公司接口有选服概念,登陆之后选服创建角色这种情况,所以详情接口独立出来是很正常的事,具体这种并不是什么错误做法也不存在懒不懒的问题
    chenPiMeiHaoChi
        19
    chenPiMeiHaoChi  
       2023-09-25 14:03:45 +08:00
    硬要这么说也没啥问题,因为有的可能是登录去的鉴权服务,获取用户信息去的用户服务。鉴权服务里根据业务系统不同有自己的逻辑,可能再去调其他第三方/子系统的登录。
    cheng6563
        20
    cheng6563  
       2023-09-25 14:04:13 +08:00
    挺正常的,账号和用户信息可能并不是绑定的,你登录的这个账号可能可以用于多个后台系统,这时在登录时就不适合返回用户信息。
    dqzcwxb
        21
    dqzcwxb  
       2023-09-25 14:05:19 +08:00
    他是不是 get 获取资源,delete 删除资源
    ciki
        22
    ciki  
       2023-09-25 14:14:06 +08:00
    看场景吧,大多数情况都是值返回 token 。如果你这个场景需要用户信息,直接返回能省很多事那也不是不可以
    liuidetmks
        23
    liuidetmks  
       2023-09-25 14:19:32 +08:00
    碰到这样同事,难搞哦,顺手的事情都不愿意支持
    cctvabu
        24
    cctvabu  
       2023-09-25 14:24:30 +08:00
    这都是看业务了,不过如果非要说的话我支持分离获取
    gniviliving
        25
    gniviliving  
       2023-09-25 14:28:47 +08:00   ❤️ 3
    登录警察虽迟但到
    登录警察统计:
    使用登录:7 人
    使用登陆:4 人
    wu00
        26
    wu00  
       2023-09-25 14:28:49 +08:00
    一般不返回,要获取用户信息单独请求;
    token 里面最多带上用户静态信息比如 id ,其它动态信息随时会改
    SACKJJKLL
        27
    SACKJJKLL  
       2023-09-25 14:29:29 +08:00
    可以返回用户脱敏信息,主要不能有密码,或者采取 token 存用户 id 然后二次查询用户脱敏信息,看业务需求
    8355
        28
    8355  
       2023-09-25 14:30:06 +08:00
    auth 服务通常只会返回基本信息,够客户端做一般初始化操作,小应用同表一起返回也可以,大应用一般是区分接口返回的,
    unco020511
        29
    unco020511  
       2023-09-25 14:35:56 +08:00
    一般是不返回的
    superchijinpeng
        30
    superchijinpeng  
       2023-09-25 14:37:17 +08:00
    不返回啊
    abear
        31
    abear  
       2023-09-25 14:39:19 +08:00
    一般是不返回的,没有 getUserInfo 的接口都是魔鬼。每次刷新都不知道当前用户是谁
    broken123
        32
    broken123  
       2023-09-25 14:42:52 +08:00   ❤️ 1
    是的,正常来说 app 端只会返回 token ,在 heade 里面,然后去获取 userInfo 信息。从后段微服务架构来说就是这样的设计的。 但是其实也可以聚合的。也不是绝对的,他那边可以多写一个接口聚合,如果有现成的接口 你直接几下写了就完事。也不复杂。些许小事罢了。我现在就是 你咋个设计我就咋个写 不愿意争论这些了。客户端就一个人 很难犟得过后端几个人。
    broken123
        33
    broken123  
       2023-09-25 14:43:18 +08:00
    反正都能做 ,无所谓了。懒得麻烦。
    brader
        34
    brader  
       2023-09-25 15:00:43 +08:00
    这个其实都行,看后端心情,前端有什么用什么就行了。
    因为用户信息这个接口,复用率非常高,有些后端会觉得提供了专门接口了,就不会在附加返回这个信息给前端了,这种流派的后端一般比较坚持模块化、接口单一性。
    但是往往很多前端比较喜欢的是面向页面提供接口,希望后端一个接口就把当前页面需要的数据全部返回来。
    oppoic
        35
    oppoic  
       2023-09-25 15:02:14 +08:00
    我们是这样的:登录只返回成功,不返回 token 这个字符串,token 由后端在账号密码校验之后写到当前域的 cookie 里(开发、测试、线上的域名和 cookie 键是不同的,后端配置后端写)

    前端拿到登录接口的 ok 返回,就直接跳转首页开始调接口,同时也不用前端手动把 token 携带到 header 里之类的,http 请求会自动携带当前域的 cookie ,后端根据配置的 cookie 键取,然后校验

    最终流程是这样:用户访问首页,前端不判断是否有 cookie (前端不关心任何登录状态,由后端判断),直接调 UserInfo 接口,后端发现没有 cookie 返回特定 code ,前端跳转登录页

    用 cookie 的好处是:最简单最原生的方案实现多个二级域名站点的单点登录
    me1onsoda
        36
    me1onsoda  
       2023-09-25 15:06:10 +08:00
    不给用户信息也是有充分理由,单一原则。登录就是登录
    rm0gang0rf
        37
    rm0gang0rf  
       2023-09-25 15:06:53 +08:00
    选择困难症初期患者
    lzgshsj
        38
    lzgshsj  
       2023-09-25 15:08:04 +08:00
    一般这种时候就是前端去搞 BFF 的契机了
    lujiaxing
        39
    lujiaxing  
       2023-09-25 15:08:12 +08:00
    不一定.
    图方便的话登录之后给返回用户信息没毛病.

    但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非.
    masterclock
        40
    masterclock  
       2023-09-25 15:11:33 +08:00
    登录实体未必是用户,未必关联了用户,未必有权限获取用户信息
    登录服务器未必有用户的信息
    cnoder
        41
    cnoder  
       2023-09-25 15:27:16 +08:00
    你们除了登录接口会不会还有地方要获取用户信息,如果有,那就最好单独加个接口,不然两个接口返回一些结构一致的信息也是冗余。
    kingjpa
        42
    kingjpa  
       2023-09-25 15:34:50 +08:00
    都合理,各有各的考虑
    flyqie
        43
    flyqie  
       2023-09-25 15:44:13 +08:00
    看心情。

    但个人不会登陆接口返回用户信息。
    QlanQ
        44
    QlanQ  
       2023-09-25 16:03:45 +08:00
    不返回,因为我必须要给前端一个获取用户信息的接口
    你也不想,前端获取用户信息的来源有两个吧,这样不是更麻烦?
    987N
        45
    987N  
       2023-09-25 16:06:00 +08:00
    没错啊,登录只返 Token ,用 token 再去拿用户信息
    ShuWei
        46
    ShuWei  
       2023-09-25 16:28:55 +08:00
    你们打一架,谁赢了听谁的,相信我,配合愉快才是最重要的,没有那么多所谓的规矩和经验要遵守
    zoharSoul
        47
    zoharSoul  
       2023-09-25 16:30:17 +08:00
    是的, 这都不是一个服务, 甚至可能不是一个组的, 怎么返回?
    lowett
        48
    lowett  
    OP
       2023-09-25 16:31:03 +08:00
    @ShuWei 没有这么严重,就了解下这方面的情况。 我公司是都放会的,就这个人不返回
    Goooooos
        49
    Goooooos  
       2023-09-25 16:31:29 +08:00
    如果对方说不出两者优缺点,一律不用理会
    darklost
        50
    darklost  
       2023-09-25 16:32:28 +08:00
    可以登录套一层 GraphQL 解决一切 /狗头
    pkoukk
        51
    pkoukk  
       2023-09-25 16:53:45 +08:00
    不返回,谁知道你登录之后要干啥业务,不同的业务领域可能有各自的数据,还不是得再拉一遍
    jsq2627
        52
    jsq2627  
       2023-09-25 18:21:32 +08:00 via iPhone
    按照 OAuth 2.0/OIDC 的精神,登录过程就是从 token endpoint 获取 id token ,并不返回用户信息
    jsq2627
        53
    jsq2627  
       2023-09-25 18:22:46 +08:00 via iPhone
    @jsq2627 但是 id token 通常是个 JWT ,为了方便可能也会塞一些不变的用户信息,比如 email
    buffzty
        54
    buffzty  
       2023-09-25 19:49:57 +08:00
    登陆接口必须返回个人信息,不然就多了一个串行流程.他就是懒和菜
    设计得好的代码 直接调个方法加个字段就行了,他那个估计得再写一遍逻辑 他肯定懒得写, 菜是原罪
    securityCoding
        55
    securityCoding  
       2023-09-25 22:05:30 +08:00 via Android
    不返回
    IvanLi127
        56
    IvanLi127  
       2023-09-26 00:49:47 +08:00 via Android
    登录原则上不返回用户信息,这对前后端都省事。前端正常都是先请求用户信息,401 后才跳登录,登录完回去重新走原来逻辑就完事了。后端也是,登录接口完全不用处理要返回什么信息,干干净净,后面改接口也不会因为这个漏改。
    utodea
        57
    utodea  
       2023-09-26 07:57:24 +08:00
    @lowett 有点好奇什么场景需要在登录接口返回用户信息?还是单纯只是不想多请求一个接口而已?
    looveh
        58
    looveh  
       2023-09-27 11:16:23 +08:00
    我们公司就是这样的,登录只返回 token ,然后用 token 请求用户信息
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1217 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 23:48 · PVG 07:48 · LAX 15:48 · JFK 18:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.