这是一个创建于 407 天前的主题，其中的信息可能已经有所发展或是发生改变。
登录只是为了拿 token ，成功后要调用用户信息接口。
经历过的项目都有返回用户信息，可能个人经历有局限，问下大家是怎样的
 |
1
craiet 2023-09-25 13:17:52 +08:00
是的
|
 |
2
EEEEx 2023-09-25 13:18:08 +08:00
返回啊, 然后也有用户信息接口
|
 |
3
MossFox 2023-09-25 13:21:53 +08:00
网页应用吗，如果 token 是存在本地的，登陆拿到 token 之后调用请求用户信息的接口可以确保 token 是被正确保存了的。
如果使用的是 Cookie 存储 token ，在跨域 iframe 里面设置 Cookie 会失败。如果用其他方式的存储，用户如果禁用了 Cookie ，基本上所有 Storage API 都会在访问时抛出异常（包括 localStorage ）。这些情况都算是，登陆请求成功但是 token 没有办法被保存的情境。 我见过的大约只有上面这种了，楼下补充看看。 |
 |
4
chinagxwei 2023-09-25 13:22:21 +08:00
登录只返回登录账户信息，用户信息要单独获取
|
 |
5
k9982874 2023-09-25 13:22:26 +08:00  2
这玩意哪有什么规范，看情况，看心情。他就是懒。
|
 |
6
thinkershare 2023-09-25 13:25:30 +08:00
看心情，也可也经用户基本信息放置到 token 里面，不过用户的 profile, 一般都是调用独立接口去获取到，比较认证和用户信息没那么强的关联性，特别实在 OAuth2 这种授权体系下。
|
 |
7
lowett OP 项目是 app ，token 在 user 里面
|
 |
8
lambdaq 2023-09-25 13:26:22 +08:00
> 正常情况下登录接口不返回用户信息
很符合 RESTful 原教旨份子 给我的刻板印象。 |
 |
9
opengps 2023-09-25 13:26:44 +08:00
这种设计没什么规定，因为用 token 可以去拿所有授权内的信息。
可能为了方便，会多返回一个用户信息的 id 使用 |
 |
10
AoEiuV020JP 2023-09-25 13:28:19 +08:00
有点坑，我们是登录返回一部分，但不够，还得调用户信息接口，
|
 |
11
ysy950803 2023-09-25 13:30:09 +08:00
他想摸鱼，不想做，没什么所谓的规范和铁律。
而且其实很多后端和前端的交互逼事儿，不是他写就是你写，后端写灵活性更大，反正就那么些接口调来调去。 |
 |
12
MeteorCat 2023-09-25 13:32:26 +08:00 via Android
玩家详情单独接口（用户详情记录大量最后充值时间最后充值金额小游戏签到这种，实际上登陆不需要这些），登陆只返回上次登陆时间 IP 简单信息
|
 |
13
Tink 2023-09-25 13:49:30 +08:00
这不是看需求吗
|
 |
14
vikaptain 2023-09-25 13:50:10 +08:00
我一般会顺带返回一些基本信息，像用户名，姓名这些。其他的更详细的信息就走详情接口
|
 |
15
yidinghe 2023-09-25 13:52:06 +08:00
考虑到登录授权和用户信息属于不同的服务，请求两次是方便后端服务进行重构治理的，否则的话就等于是强行要求登录授权服务绑定用户信息服务。
|
 |
16
neptuno 2023-09-25 13:57:28 +08:00
大厂是这样的，小厂，就那么几个接口，登陆直接能返回，为啥还要再调用一次。
|
 |
17
sjn9588 2023-09-25 13:58:27 +08:00
那打开 app 自动登录场景下，难道用来记住用户密码来做嘛？
|
|
18
MeteorCat 2023-09-25 14:02:00 +08:00 via Android
登陆接口越简单越好，游戏公司接口有选服概念，登陆之后选服创建角色这种情况，所以详情接口独立出来是很正常的事，具体这种并不是什么错误做法也不存在懒不懒的问题
|
 |
19
chenPiMeiHaoChi 2023-09-25 14:03:45 +08:00
硬要这么说也没啥问题，因为有的可能是登录去的鉴权服务，获取用户信息去的用户服务。鉴权服务里根据业务系统不同有自己的逻辑，可能再去调其他第三方/子系统的登录。
|
 |
20
cheng6563 2023-09-25 14:04:13 +08:00
挺正常的，账号和用户信息可能并不是绑定的，你登录的这个账号可能可以用于多个后台系统，这时在登录时就不适合返回用户信息。
|
 |
21
dqzcwxb 2023-09-25 14:05:19 +08:00
他是不是 get 获取资源,delete 删除资源
 |
 |
22
ciki 2023-09-25 14:14:06 +08:00
看场景吧，大多数情况都是值返回 token 。如果你这个场景需要用户信息，直接返回能省很多事那也不是不可以
|
 |
23
liuidetmks 2023-09-25 14:19:32 +08:00
碰到这样同事，难搞哦，顺手的事情都不愿意支持
|
 |
24
cctvabu 2023-09-25 14:24:30 +08:00
这都是看业务了，不过如果非要说的话我支持分离获取
|
 |
25
gniviliving 2023-09-25 14:28:47 +08:00 3
登录警察虽迟但到
登录警察统计： 使用登录：7 人 使用登陆：4 人 |
 |
26
wu00 2023-09-25 14:28:49 +08:00
一般不返回，要获取用户信息单独请求；
token 里面最多带上用户静态信息比如 id ，其它动态信息随时会改 |
 |
27
SACKJJKLL 2023-09-25 14:29:29 +08:00
可以返回用户脱敏信息,主要不能有密码,或者采取 token 存用户 id 然后二次查询用户脱敏信息,看业务需求
|
 |
28
8355 2023-09-25 14:30:06 +08:00
auth 服务通常只会返回基本信息，够客户端做一般初始化操作，小应用同表一起返回也可以，大应用一般是区分接口返回的，
|
 |
29
unco020511 2023-09-25 14:35:56 +08:00
一般是不返回的
|
 |
30
superchijinpeng 2023-09-25 14:37:17 +08:00
不返回啊
|
 |
31
abear 2023-09-25 14:39:19 +08:00
一般是不返回的，没有 getUserInfo 的接口都是魔鬼。每次刷新都不知道当前用户是谁
|
 |
32
broken123 2023-09-25 14:42:52 +08:00 1
是的，正常来说 app 端只会返回 token ，在 heade 里面，然后去获取 userInfo 信息。从后段微服务架构来说就是这样的设计的。 但是其实也可以聚合的。也不是绝对的，他那边可以多写一个接口聚合，如果有现成的接口 你直接几下写了就完事。也不复杂。些许小事罢了。我现在就是 你咋个设计我就咋个写 不愿意争论这些了。客户端就一个人 很难犟得过后端几个人。
|
|
33
broken123 2023-09-25 14:43:18 +08:00
反正都能做 ，无所谓了。懒得麻烦。
|
 |
34
brader 2023-09-25 15:00:43 +08:00
这个其实都行，看后端心情，前端有什么用什么就行了。
因为用户信息这个接口，复用率非常高，有些后端会觉得提供了专门接口了，就不会在附加返回这个信息给前端了，这种流派的后端一般比较坚持模块化、接口单一性。 但是往往很多前端比较喜欢的是面向页面提供接口，希望后端一个接口就把当前页面需要的数据全部返回来。 |
 |
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 的好处是：最简单最原生的方案实现多个二级域名站点的单点登录 |
 |
36
me1onsoda 2023-09-25 15:06:10 +08:00
不给用户信息也是有充分理由，单一原则。登录就是登录
|
 |
37
rm0gang0rf 2023-09-25 15:06:53 +08:00
选择困难症初期患者
|
 |
38
lzgshsj 2023-09-25 15:08:04 +08:00
一般这种时候就是前端去搞 BFF 的契机了
|
 |
39
lujiaxing 2023-09-25 15:08:12 +08:00
不一定.
图方便的话登录之后给返回用户信息没毛病. 但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非. |
 |
40
masterclock 2023-09-25 15:11:33 +08:00
登录实体未必是用户，未必关联了用户，未必有权限获取用户信息
登录服务器未必有用户的信息 |
 |
41
cnoder 2023-09-25 15:27:16 +08:00
你们除了登录接口会不会还有地方要获取用户信息，如果有，那就最好单独加个接口，不然两个接口返回一些结构一致的信息也是冗余。
|
 |
42
kingjpa 2023-09-25 15:34:50 +08:00
都合理，各有各的考虑
|
 |
43
flyqie 2023-09-25 15:44:13 +08:00
看心情。
但个人不会登陆接口返回用户信息。 |
 |
44
QlanQ 2023-09-25 16:03:45 +08:00
不返回，因为我必须要给前端一个获取用户信息的接口
你也不想，前端获取用户信息的来源有两个吧，这样不是更麻烦？ |
 |
45
987N 2023-09-25 16:06:00 +08:00
没错啊，登录只返 Token ，用 token 再去拿用户信息
|
 |
46
ShuWei 2023-09-25 16:28:55 +08:00
你们打一架，谁赢了听谁的，相信我，配合愉快才是最重要的，没有那么多所谓的规矩和经验要遵守
|
 |
47
zoharSoul 2023-09-25 16:30:17 +08:00
是的, 这都不是一个服务, 甚至可能不是一个组的, 怎么返回?
|
 |
49
Goooooos 2023-09-25 16:31:29 +08:00
如果对方说不出两者优缺点，一律不用理会
|
 |
50
darklost 2023-09-25 16:32:28 +08:00
可以登录套一层 GraphQL 解决一切 /狗头
|
 |
51
pkoukk 2023-09-25 16:53:45 +08:00
不返回，谁知道你登录之后要干啥业务，不同的业务领域可能有各自的数据，还不是得再拉一遍
|
 |
52
jsq2627 2023-09-25 18:21:32 +08:00 via iPhone
按照 OAuth 2.0/OIDC 的精神，登录过程就是从 token endpoint 获取 id token ，并不返回用户信息
|
|
53
jsq2627 2023-09-25 18:22:46 +08:00 via iPhone
@jsq2627 但是 id token 通常是个 JWT ，为了方便可能也会塞一些不变的用户信息，比如 email
|
 |
54
buffzty 2023-09-25 19:49:57 +08:00
登陆接口必须返回个人信息,不然就多了一个串行流程.他就是懒和菜
设计得好的代码 直接调个方法加个字段就行了,他那个估计得再写一遍逻辑 他肯定懒得写, 菜是原罪 |
 |
55
securityCoding 2023-09-25 22:05:30 +08:00 via Android
不返回
|
 |
56
IvanLi127 2023-09-26 00:49:47 +08:00 via Android
登录原则上不返回用户信息，这对前后端都省事。前端正常都是先请求用户信息，401 后才跳登录，登录完回去重新走原来逻辑就完事了。后端也是，登录接口完全不用处理要返回什么信息，干干净净，后面改接口也不会因为这个漏改。
|
 |
58
looveh 2023-09-27 11:16:23 +08:00
我们公司就是这样的，登录只返回 token ，然后用 token 请求用户信息
|
Select Language