之前公司的前端是对参数做 aes 加密，后端解密，只是相对破解门槛较高而已。还有密码应该要加密也不会用 md5 这种不可逆的方式吧，不然密码规则后端怎么校验

1. 接口原子性没太明白，如果是数据库操作的原子性的话，就是开启事务。如果是接口的，那加个分布式锁？
2. tx 一般在 service 层有个接口实现在 ctx 中注入 orm ，接口的实现在 repo 层，一般就如下使用方式：
```
type Transaction interface {
TX(ctx context.Context, fn func(ctx context.Context) error) error
}

func (d *Repo) TX(ctx context.Context, fn func(ctx context.Context) error) error {
return d.db.Transaction(func(tx *gorm.DB) (err error) {
defer func() {
if e := recover(); e != nil {
err = fmt.Errorf("%#v", e)
// log
}
}()
ctx = context.WithValue(ctx, contextTxKey{}, tx)
err = fn(ctx)
return err
})
}

```
service 层调用各 repo：
```

s.tm.TX(ctx, func(ctx context.Context) error {
if err := s.Repo1.Create(ctx, ...); err != nil{
return err
}
return nil
})
```
3. 个人会封装一层，用于常规的 curd 实现，然后各个 dao 不通用的部分单独写

用户名：github_8621

联通畅游卡，29 元 135G+100 分钟通话
8 元流量王套餐用于保号，好像是 30 分钟通话+200M 流量
之前是 5 元的保号套餐，小天神卡。

@Zys2017 直接找客服转，打电话或者 app 或者公众号人工客服，都可以转的

联通畅游卡，29 块钱，135G + 100 分钟通话，联通官方有这个套餐，如果是浙江省内卡还可以老用户直接转。但有合约，2 年合约，合约结束不取消会自动享受优惠

有房有车，还有现金流 300W ，难道躺平不够么？还有啥好焦虑的，光 300W 存余额宝，一年也可以 6-7w 吧，更何况现在工作又没丢

大多数考核都是看领导的喜好，上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样，有的业务产出明显，有的业务重调研，产出效果一般。
每个人职级与工资不一样，这是一个重要的维度其实，但好多可能都放在一起去考核。
所以有这么多不确定因素在，这绩效大多数还是形同虚设，最后还是变成领导喜好去打

红利也不是每个人都能吃到，在红利期间，没多跳，就吃不到。还有买房，没有格局的也没吃到。每个人都以为时间倒退多少年，就能吃尽那个时代的红利，但有没有想过，你是在知道结果的时候去回看的，不是身处在那个时代的人。如果你和马云马化腾一个时代，你就能和他们达到一样的成就么？

最后一天

所以这种小件是有相关的旗舰店还是啥，怎么筛选靠谱的店？ 去年疫情放开，在 pdd 上买了温度计，结果温度计都上不了 36 度...坑得很

如果要使用 markdown ，把 confluence 给排除了，那个 markdown 插件很难用，而且样式很难看

@xiaomada 嗯，好的，非常感谢，我去体验一下你上面说的一些 idaas 产品，加深一下相关概念的理解。

@xiaomada id_token 按你的说法，只用于解析出来 userId ，如果子系统 user 表不存在，则写入到 user 表，然后子系统自己想怎么处理系统会话，它自行处理，其实这时候已经与 id_token 就无关了？ 还有 id_token 与 access_token 的区别在于本身包含了用户的一些信息，但 access_token 如果需要获取用户信息的话，还需要通过 userinfo endpoint 去获取一次，如果本身不介意再去获取一次的话，其实可能就不需要 id_token 了？我这样理解对么？

@xiaomada 谢谢，不同域名下的实现方式对我很有帮助。对于单点登录与登出，oidc 的 core 协议里确实没有，但有几个补充协议，好像通过前端通道实现的方式和你下面说的不在同一个域名下的实现方式很类似，就是需要 iframe 去做辅助同步通知到其他域。

基于 oidc 协议的，最后返回的 id_token ，我在想，如果使用传统的 cookie + session 的方式，那他协议返回的 id_token 到底怎么使用呢？看了一些开源的基于 oidc 协议作身份认证的产品，在应用的实现范例大多数是怎么通过授权码去获取到 id_token 这些，就点到为止了

@xiaomada 我们的目标是所有的都会接入到这个账号体系中，包括 gitlab 之后也会接入，但首先是要满足我们整个云平台下的各自子系统的登录，所以最后选择了比较统一的 oidc 协议。

@FuryBean 嗯，这么说流程还是蛮清晰的。但其实我纠结的点在哪呢，就是明明使用 oidc 了，那边也返回 id_token 了，但是这个 id_token 的正确使用指南我 get 不到，你像你说的这个流程，感觉更像是传统的 sso 解决方案，用不用 oidc 其实没啥差别，我请求 oidc.com ，只要告诉应用认证成功和用户信息就 ok 了，应用的 session 自己维护，也不需要和 id_token 有任何关联

@tool2d 开放给第三方应用的确实得传 access_token ，但我现在的应用场景是单点登录，我们一个大平台，里面可能有各个子系统，这些系统其实都不算是第三方的应用，理论上是属于我们公司自己的产品，oidc 这边其实就是要做一个统一认证平台，在 api 的授权访问这块，其实有 rbac 的鉴权模块统一处理的。从需求方面，我觉得我们可能用的是 id_token, 不是 access_token

@tool2d 谢谢，看这图明白了点，id token 是用于认证，access token 是用于 api 访问权限判断。那我请求一个 api ，如果后端去解析 id token 的 jwt ，那前端不是得把 id token 与 access token 一并传给后端？