V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  justdoit123  ›  全部回复第 4 页 / 共 14 页
回复总数  266
1  2  3  4  5  6  7  8  9  10 ... 14  
1. 技术上并不是需要用户同意。实际上你爱怎么用,就怎么用。但是欧盟有法律限制,具体不是很清楚,貌似是第三方 cookies 的使用需要用户同意。因为这些第三方 cookie 基本是 google ads 之流,轻松可以追踪到用户的浏览行为。你自己网站需要用的必要 cookies 不受此限制。虽然只是欧盟有这些限制,但是不知道为什么很多网站都把这种要“用户同意使用 cookie” 的弹框对所有地区的访客开启。我曾经试过访问一些国际大企业的网站,比如 Google 搜索,当你把代理设置在欧盟国家的时候,会弹出一个条款要你同意,但是代理设置成欧盟外的地区,这个弹框又不会出现。

2. 回到技术层面,你这种方案有一定风险。cookies 只是存储介质,如果只是存储一些 session 统计等无关紧要的信息,那你这样做也所谓。但是当 cookie 存储的信息是身份验证信息的时候,你的这种处理方式会带来一定风险。js 能把 cookie 丢到 localStorage ,意味着你的这种 cookie 可以被 JS 读取,意味着如果网站有 XSS 漏洞,用户的 身份验证信息会被攻击者偷走。一般而言,用来存储身份验证信息的 cookie 不需要用户同意。一般要设置成 Http-Only ( JS 无法读取,也就不会被 XSS 攻击者窃取)、Secure (只能在 https 这类安全通讯协议上传输)、SameSite 至少设置为 Lax (老版本的浏览器并没把 Lax 设为 SameSite 的默认值)。
有时候真的觉得这些不重要。以前喜欢折腾 emacs 、vim ,那时候要是有 vscode ,估计也会折腾 vscode 。工作几年后,基本只用 JetBrain 系列的东西。环境这种东西,开箱即用是最好的,或者积累足够一定的痛点后,再去想着优化即可。

还是以前的一位同事说得在理,软件开发的瓶颈在思维又不在编码上。思路错了,你写得再快又如何?
184 天前
回复了 Saber299 创建的主题 Java 分布式事务到是什么
@bthulu {哭笑脸} “打日志警告人工处理”,项目初期很受用。
个人还是不太看好纯社区驱动的东西。

忘记以前看的哪本书,貌似是讲 CSS 的,那个作者说,要伺候一群来自不同公司的 web 委员会成员,就像要伺候十几种猫一样,太难伺候了。


有社区、有一定的开放性,然后再有一个强大的企业来引导,个人感觉是比较好的。
187 天前
回复了 justdoit123 创建的主题 科技 后端异步状态问题
@Zhuzhuchenyan 好,感谢~
右边的 Ctrl 、Alt 、Command 一般很少很少用到,所以可以自己用来改成一些快捷键的映射。这样大部分情况下不影响键盘的本来面貌,又可以扩展一些快捷键。我个人只用两个改键方案:

1. 右 Alt + p/n/b/f 映射成 剪头上下左右,接近 Emacs 的移动光标方案;
2. 右 Command 映射成 Ctrl + Alt + Command + Shift 。这样可以很方便的触发很特殊的四个修饰键的快捷键方案。配合一些快捷键注册服务使用。比如,右边 Cmd + T 就是切换到终端,+ C 就是切换到 Chrome ,+ P 就是切换到 PyCharm 。
@zy445566
@tool2dx

先前实验下来的确有这个发现。浏览器对于当前 document 访问,是会忽略缓存相关的 Header 。即便我问的这个 `immutable` 也是会忽略的。

iframe 确实没实验过。感谢分享!
@sagaxu 你说的那是协商缓存吧? Expires 与 Cache-Control max-age=XXX 是强缓存。
@bxb100 感谢~ 这个 Q&A 说得很清楚。
@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 服务供应端实现的时候,是不是可以通过抛出异常然后在出口统一拦截这类业务异常转成正常数据交换的实现方式?当然,这类所谓的“业务异常”并不是程序错误,就不需要上报监控了,不混入其它的错误监控中去。
1  2  3  4  5  6  7  8  9  10 ... 14  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2546 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 03:52 · PVG 11:52 · LAX 19:52 · JFK 22:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.