@lovelylain 浏览器为了向后兼容，依然允许表单构建的请求进行跨域。而表单请求只有 GET/POST 两种 method 。这种请求，是有办法自动带上目标网站的 Cookie 的，从而实现 CSRF 攻击。

我认为是可以的。如果请求允许 PUT ，那么就无法在浏览器端构建出 CSRF 攻击。

但是，这种防御方式有点自损八百的感觉。

另外，我心中也有一个疑惑，为什么有的人要把 CSRF token 存放到 session 里？我感觉这种绑定的意义不大，还增加服务的负担。

不用讨论这样做 CORS 。我只是读文档，有疑惑而已。

楼上 #1, #6 说的是正解，非常感谢~ 意思就是说，简单请求 **只是** 不触发预检，并不是说这类请求能绕过 CORS 保护。

而 script 、img 、link 、form 这类标签构造出来的请求能绕过 CORS 保护，是为了 **向后兼容**。

太正常了。

web 环境跟 server 环境经常混为一谈。狭义一点的 web 环境，应该是指浏览器环境。 但是 http server 不是只服务于浏览器。

经典的几个莫名其妙的问题以及神奇操作。

1. cookie 与 session 有什么区别？二者不是之间替代品，没什么好比较。
2. cookie 与 jwt token 有什么区别？二者不是之间替代品，没什么好比较。
3. 在浏览器环境，把 jwt token 塞 Authentication header 里。那请问你的 jwt token 不是需要让 js 访问吗？那不是等于会泄露在某处？
4. 把公开的 API 加上 CSRF 保护。这类 API ，一般会用服务于 sdk 、app 、server 2 server ，这种场景下防什么 CSRF 攻击。CSRF 攻击只在浏览器发生。server 可以分流，身份信息 放在 cookie 里的，是浏览器流量，需要 CSRF 保护，放在 Authentication header 里的，是一些非浏览器流量，不需要 CSRF 保护。
...

GraphQL 之前的项目用过。现在接一些第三方服务也会用到。反正还是喜欢不起来，感觉国外比较受欢迎。

我不喜欢大概有两点：
1. 引入新的 DSL 。我觉得 API 对接还没到需要引入一个 DSL 的地步，围绕着这个 DSL 有好多生态要搭建，做不好体验就比较差。写 query 时的字段补全、嵌套 format 等等问题。感觉体验不太好。
2. 容易写成一个臃肿的请求。

没有细看过 trpc ，它跟 grpc 比起来有什么优势吗？ grpc 也能生成 TS client ，不过感觉确实有类型丢失。

感谢 感谢～ 感觉拓宽了视野，也清晰了很多。

回到这个 “业务异常” 上来。我在 rpc 服务供应端实现的时候，是不是可以通过抛出异常然后在出口统一拦截这类业务异常转成正常数据交换的实现方式？当然，这类所谓的“业务异常”并不是程序错误，就不需要上报监控了，不混入其它的错误监控中去。

@povsister

我可不可以这样理解：

1. 对于我描述的这类异常，应该属于 “业务异常”。说是异常，其实是正常的数据交互。类似的还有，邮箱已被使用、账号或密码不存在等。这些不属于程序错误，监控也不需要关心这些业务异常。

2. 还存在一类异常，为了区分称为“程序错误”吧。这些是程序员真正需要关心的，需要有你说的描述、场景、debug 信息。我能想到的典型，可能是 “配置不存在”、验证 Token 解析失败这类错误。总之是不符合预期的、需要监控关心的问题。

话说，才发现 coding 节点算是 CodingNet 的营销节点。。。

@timethinker 感谢～

我有时候会想去做工业软件开发。因为会预设的认为（可能事实并非如此）工业软件的需求是清晰的。就像建设一座桥梁一样。一个具体的桥梁，其宽度、长度、承受力需求是确定的。然后会进行设计，确定什么样的结构、什么样的材料等。然后进行施工建设。

不知道现实中的工业软件开发是不是我设想的这样。

同样用现实中的桥梁做比喻，互联网的短平快，就像是先横一根木头过河，一根不够就两根，木头不稳就两把用人扶着，怎么实现快怎么来，先“能过河”再说。总算有人能通过这根“桥”过了河，但是上面却说这个桥不用了。

不知道这样的比喻恰不恰当。

以前在学校会觉得技术最重要，代码最重要。工作到现在，我却感觉需求更重要，清晰的方向、牛逼的产品经理比程序员重要多了。经常看着写下的代码死掉，会让我泄气。

这。。。。。点进去看了下，TX 这个怎么都算是在干正事。

密码（或者 hash 过后的密码）终究要出现在内存里，云服务提供商是不是能从内存里直接读出密码。

安全没有绝对，做到什么程度，看被保护的对象是什么，需不需要做到那么高的层级。

服务端发一个公钥，然后在客户端把重要数据再自己加密一次也不算很费事。不过不加也就那样。


> 密码是用户自己的隐私，不想让服务提供商知道我的隐私。

我感觉这种想法很美好，现实是你这种“隐私”会像乐色一样被对待。不想泄露隐私，绝对的安全就是把自己关在一个盒子里。 当你使用服务的那一刻，很多“隐私”都已经不复存在。真那么觉得 密码 是一种隐私，那用户名（ email 等）也应该是隐私。以后要用这些东西，就每个服务都用一个随机 ID 、随机密码。这样就不会泄露“隐私”了。但是真的好累。

暂时采用 ref 的方式解决。把一些 handler 放入 ref ，类似这样：

```tsx
const handlersRef = useRef<{
submitLog?: typeof submitLog;
startClock?: typeof startClock;
}>({});
```

@Puteulanus 谢谢～ 捂脸

@lisongeee 哇哦，还有这种用法。前面没有细看，明白了。

@weixind 这个 use-query 看着不错。


关于 状态 还是 set 多不展开讨论。 我会问这个问题，是因为我在实现一个连续 timer 的需求。

1. timer 一开始是停止的，有个按钮让用户点开始；再点一次就停止。
2. 一个 timer 时间到了，需要提交数据，然后自动开始下一个 timer ，直到用户点停止为止。


那么如何在一个 timer 数据提交后，自动触发下一个？直接调用 startTimer 肯定是不行的，因为里面包含的 state 都是“旧”的。

我目前能想到的是通过 pubsub 来绕过这个问题，或者就像 1, 2 楼 说的用 ref 。