V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 39 页 / 共 56 页
回复总数  1114
1 ... 35  36  37  38  39  40  41  42  43  44 ... 56  
2021-11-19 11:00:49 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@leeg810312
我希望聊技术的人能带上点脑子,就比如 go 吹,go 吹就不能聊这些设计了吗?前面楼问过其他人,现在也问你一句:你逻辑及格了吗?

#132 回复你的你能看懂吗?
#178 的回复你也可以看一看

说自己十几年经验,一直在这断章取义、望文生义、无论据式无脑口嗨,十几年就这?十几年一直写 CURD 了是吧?只会为杠而杠是吧?

能看懂我回复再来 at 我行不?
2021-11-19 10:51:42 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@FakNoCNName 我真正在辩论的点可能大家好些人都没理解到,请参考我 #178 的回复。

> 旧的不一定过时,但总有一天会过时,新的不一定成为标准,但成为新标准的肯定是新技术。

>(技术方面聊到这里其实已经没多少可以争论的了,大家都说清了主张和原因,很多东西都是有历史原因的,也需要考虑成本,最后总有一方需要改变。)

这些我也是都认同的,前面几楼也解释了一些。因为好些位看到个关键字就断章取义了,把我意思都给曲解了 :joy:
2021-11-19 10:47:31 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@twl007
> 感觉你可以去跟 Box API 的团队讨论下 API 设计 人家 get put post 语义明确 用起来一点毛病没有
> 不知道 Box 算不算特定领域亦或是人家对安全要求低 反正没见人家有这个问题

我好像没说过所有 PUT/DELETE 不安全吧,包括转的帖,也是说特定场景下的不安全比如文件服务相关的,而比如前面其他人提到的云厂 API PUT ,以及你提到的 box google ,API 接口控制好,我也没说有安全问题,但这些都是控制好的前提下,我们不能指望所有团队都按照你提到的厂的规范,尤其这世上还存在很多健在的 php asp jsp 项目。

我之前有说,在这个帖子里关于 PUT 的观点包括几个方面:
1. 安全规避以及替代成本不高
2. 与其他方案对比的优劣
3. 工程、跨工种 /部门 /公司协作

我并没有说 REST 就一定不安全、不能用。但是 PUT 在现实场景里,就是有的人会面临 1 和 3 的额外的麻烦比如楼主的项目,而如果不用 PUT ,则可以免掉这个麻烦,而且抛开项目历史包袱,POST 替代 PUT 成本也可以忽略

REST 的各种 Method ,一是基于 HTTP 协议本身,二是基于社区发展实践和历史,按照工程实践形成的规范继续实践下去也 OK ,但是我说的是与其他方案对比的优劣,如我 #88 中说过的,各位没有考虑参照物对比、只是说 REST 可以用,各位跟我聊的甚至不是一个事情

#88 我已经解释了一些,各位有没有想一下,如果早期 HTTP 就没 Method ,大家还必须依赖 Method 吗?只用路由能搞定吗? RPC 的 'Method' 其实是相当于 HTTP 的路由,RPC 其实没有 HTTP 这种在路由之外额外再套上的 Method 区分,即使 GCP 文档里的 PB RPC Service 定义部分,也是直接把 HTTP Method 映射到 RPC Method 上(就是方法 /函数名),相当于我 #88 说的 路由+参数 两个维度,并不需要三个维度。其他的很多自定义二进制协议场景也是类似,路由 /方法名 /命令号 + 参数 这两个点就足够了,也是并不需要非得搞成三个维度

我真正想聊的,是自底向上从不同的设计方案来对比 A 和 B 两种方案或者设计 /使用方式,哪种更简化、更省更好,而不是各位这种多是自顶向下从如何使用 A 或者在 A 的历史实践中形成的经验如何好用。

所以跟 box 聊设计或者跟 google 文档对比,跟我说的这些都没什么关系,希望有人能 get 到我说的点,而不是继续跟我聊 A 方案为什么好用。
2021-11-18 23:49:10 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@TossPig @iseki
刚洗完澡头发还没干,所以又来补一波。。。

其实相比于 RESTFull ,post+struct body 方式的路由也好、参数也好(甚至路由也放到 body struct 字段里,但是比如 nginx 日志之类的不友好、需要插件解码再日志才行),更统一,比如参数,不需要再去 header 的 kv 、form 或者 body 各种地方取,而且写法上,以 go 语言为例,一个 ctx.Bind(&args),后续的参数就都可以是结构体字段,干净得很。有的人喜欢省事用 map 类型,然后取到 interface{}再解析,这种不推荐,理由跟强弱类型语言做工程的优劣类似,而且项目足够规范,就应该协议制定阶段定好类型,然后就都很规范干净。当然,不同语言,强类型、弱类型、还有 java 这种带注解的,对于这种方式参数使用的便利未必一样。但至少在 go 和其他一些语言领域,或者从设计、获取参数来源上,确实是简便了一些的。而且 RESTFull 多种方法相关的,我前面说路由命名一样能解决,RPC 也一样的道理,如果命名解决不了,那 RESTFul 也未必能解决的了、只是增加一个维度的复杂度而已。

一些传统业务,社区已经既有很多成熟的解决方案,比如企业级、电商、管理后台系列、金融相关的很多,还有一些语言优势领域比如 PHP ROR 各种擅长的中小项目领域,这些成型的成熟方案改造使用 post+struct body 没什么必要,或者像楼主这种,公司已经形成了比较统一的项目规范,改个另类出来反倒增加团队负担,也没必要。
但是近年的一些新项目,尤其 go 语言这种,因为没有历史包袱,主流的框架以及相对中等以上水平的团队,很多都会选择 post+struct body 的方式。所以之前其他楼一些同学说我应该跟上时代,我都觉得他们有点说反了,可能他们才是没跟上时代吧 :joy:

另外关于 websocket ,我这有个 go 的 rpc 框架,支持 websocket 作为 transport 层,而且不只是 rpc ,可以服务端主动发消息给客户端,可以避免线头阻塞,可以乱序响应,而且能够支持更多业务场景比如推送、IM 、游戏等等:
github.com/lesismal/arpc

go 的 rpc 框架里,性能我不敢吹第一,但哪个框架说它第一的话我也不服。。。这有一份相对客观公正的 go rpc benchmark:
github.com/micro-svc/go-rpc-framework-benchmark

这里有个 websocket 聊天的简单例子:
github.com/lesismal/arpc/tree/master/examples/webchat

如果各位有兴趣玩 go ,欢迎多多交流
2021-11-18 22:46:50 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
辛苦攒的 v 币,今天消耗了太多,怀疑一些层主上来就口嗨是过来骗我 v 币的,真是坏得很呢。
这个帖子不想再扯了,睡觉了,晚安各位。
2021-11-18 22:44:08 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@iseki 嗯嗯,能保系统是第一位的,其他的慢慢演进吧,每个团队每个人都有自己的设计审美,而且是否流行与是否主流与是否优雅也通常不是绝对正相关的,大家能赚钱、能有朝一日全民不卷就好。
2021-11-18 22:40:46 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@xfriday 是的呀,怎么了,我也是被你们各位上来就口嗨给逼的呀,只能这种戏谑点方式和心态防止自己被气坏啊,所以请多理解,而且对认真聊技术的人我可是没这样说话的呀。。
2021-11-18 22:38:16 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@skinny @hack

我在这个帖子里对于 PUT 的观点包括几个方面:
1. 安全规避以及替代成本不高
2. 与其他方案对比的优劣
3. 工程、跨工种 /部门 /公司协作

前面回复的太多了,这会也快睡觉的时间了,就不挨个楼去整理了

我前面还说过好些人断章取义,望文生义、无论据式口嗨、看都没看懂上来就怼,你们对待技术真是够随便的,我得庆幸还有很多不随便的人。
2021-11-18 22:31:56 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@TossPig

> 看了半天,也没找到你前面提的三元问题

"Method + 路由 + 参数"

#86 #88 网页回复,没编辑那么细致,之前没叫三元

另外,我自己项目和熟悉的朋友的项目里,oost + struct body 挺多的,restful 的反倒没怎么见到
2021-11-18 22:27:59 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@iseki
> 至于你说 POST200 更省资源这就有点扯了,都 application/json 你跟我说省资源???

我没太懂,"我说省资源",是指我在哪一楼的来着,我全页面搜了下这个帖子里只搜到你这一楼“省资源”这几个字了
2021-11-18 21:53:27 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@xfriday 兄弟,出门左转百度,右转谷歌,请自己查一下,我就喜欢你们年轻人这种活泼劲儿 :joy:
2021-11-18 21:48:35 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@TossPig
> 流行的规范,大多数人更容易接受,读到你是 delete 请求,自然知道这里是要删除一个什么东西,读到 post 的时候,知道这里是新增了一个什么东西,不是 and,create,built 一堆动词的滥用

抛开 RESTFul 不谈,我前面提到的三元 /三个维度的问题,其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ,但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

> “用户是需要被教育的”

这个不太同一,如果我们做得更简约,比如 POST 替代 PUT ,则连教育用户都可以省掉了

——————————————————————————————————————

但公司产品统一,这个没毛病,适合你们自己当前实际情况的就是好的。good luck~ :smile:
2021-11-18 21:40:53 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@buffzty 汇编多平台也是耗神,而且不是做外挂、安全之类的没什么必要再搞了,绝大多数服务也不需要汇编级的优化,偶尔需要也是看看汇编代码琢磨下高级语言本身的优化写法,所以也是不打算了,linux net 本来也算熟。我列的两个项目一个是能支持更全面业务场景的 rpc 框架,不像其他 rpc 框架那样只能局限于 rpc ,还可以做推送、IM 、游戏之类的;另一个项目是个异步网络库,相比于其他的 golang 异步网络库,性能不低于任一,并且支持 tls/http1.x/ws ,其他异步网络库除了 gev 支持简单的 ws ,都不支持这些。这两个项目都算是 golang 领域里别人没有做好的。代理爬虫 web 框架也都是遍地,我的异步网络库 nbio 还基本兼容了标准库,所以比如 gin/echo 之类的这些都能够使用 nbio 作为网络层,然后能够节省大量协程数量和内存开销并支持单机 1000k 这种、不会像基于标准库那样协程数量爆炸、内存爆炸、调度和 gc 成本高、STW 。
这两个库目前也算版本相对稳定了,所以想找点其他好玩的又不至于消耗太大精力的,实在无聊的时候就读读其他好项目的源码了
2021-11-18 21:24:31 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
> 找你这么说,用 POST 替代 PUT ,然后一个傻帽把数据库全清空了,然后你又说 POST 不安全
文件服务的 PUT ,跟你的 api POST 接口相比,参数校验方式一样吗? webshell 那些,黑客漏洞扫描工具那些,了解吗?

> 看到底你就是个外行,还喜欢扮 “高层面”。
我扮没扮高层面我自己清楚,但咱俩谁外行你未必清楚
2021-11-18 21:21:51 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
好多断章取义,望文生义上来就怼的,服了你们了
2021-11-18 21:18:51 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@xfriday
> 我把你所有回答都看了,GET 就不能改 /删东西了

我什么时候说过这话了?我说 PUT 能删文件 == 我说 GET 不能删文件?你逻辑及格了吗小兄弟?

另外,GET 能删跟 PUT 的删法一样吗?你每层楼都看了没看懂我说 PUT 文件服务跟 api 的区别?自己不会搜一下?哪里来这么多自信上来就喷,真看了吗?真看懂了吗?
2021-11-18 21:12:34 +08:00
回复了 lesismal 创建的主题 Go 编程语言 最近犯闲,想再写点啥项目,有推荐的吗?
@rj15295774336
socket.io 用的人太少了,而且 websocket 足够用了
2021-11-18 21:11:33 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
@leeg810312
我好像没说过强制你们也别用吧?我各个楼是在对比 PUT/DELETE 相对于不用它俩的优劣以及不用它俩的成本,关联到工程、协作等相关的层面,都是在讨论更好的方式。而你们的点就是你们再用并且能用,但是这种方案就是最正确的最好的吗?
自己项目正在用和能用,跟对比其他方式是否存在缺点孰优孰劣,是两码事
流行不代表就是主流,即使主流也不等价于最优
这些我前面楼都有讲过,你们跟我辩来辩去有人认真看我说的点了吗?:joy:

所以这些楼层下来,相当于我在说 A 不如 B ,并且我解释为什么 A 不如 B ;然后你们就说你们在用 A ,你们给大厂的方案也是在用 A ,云厂也在用 A ,驴唇不对马嘴地怼我呢,多数都没怼到我聊的点上,也不提一些论据,比如说为什么 A 就是比 B 好并且好在哪些地方,或者说 A 相对于 B 没有带来更多缺点或者额外的成本(比如安全策略的设置、更新、维护,比如楼主 @TossPig 刚才回复的需要走流程写保证书,本来如果你们不用 PUT/DELETE ,就不需要这些额外的成本,当然,楼主项目历史积累的方案、不改我也理解、支持,只是如果有新项目的时候,建议改成不依赖 PUT/DELETE 的,只是建议,各位自己决定就好)

然后,既然兄弟你都也十多年经验了,跟我杠的时候就不能认真看看我在说什么吗。。。非要像个 95 后一样盲怼我,你们各位怼我的大侠扪心自问一下这样够讲武德吗 :joy:
别说什么我跟上时代潮流,除了你们的团队,还有很多团队都在用 GET/POST + 结构化 body ,甚至像我一样连 GET 都不用的,不要以为自己的圈子就是最大的最流行的圈子就是最潮流的,我上面和其他楼都说过了,流行和主流和最优都不是等价的,否则就不会有革新了。
另外,牛逼的人把复杂的事情简单化,一般的人把简单的问题复杂化,less is more ,上点年纪的多做过一些各种项目的应该要懂的。

PS: 很多交流如果允许带上图,气氛可以不那么激烈,真希望 v 站能畅快的发点 emoj ,:joy: 是我觉得比较能不互相刺激的表情,但是发不出来,各位脑补好了
2021-11-18 19:29:10 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
现在的年轻人都这么喜欢无论据方式的阴阳怪气吗?

很看好你们最新鲜的一代,但也经常感到失望。希望你们 30 、40 岁的时候不会继续这个样子吧。
2021-11-18 19:26:27 +08:00
回复了 TossPig 创建的主题 程序员 被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
我不是安全领域专业户,但是各位可以搜下 "HTTP PUT 攻击 渗透" 或者 "HTTP PUT ATTACK" 之类的,老外的、国内的都有很多相关的帖子或者演示

一些漏洞扫描软件自带功能也包括对 web 服务的 PUT 方法进行扫描

#116 楼的问题我也想统一再问一次那些说安全的各位:
"能给你开" 和 "本来就可以不用开",前者更好吗?

类似 "这只能说明你们运维菜,不足以说明 PUT 方法不安全" 这种观点,同样的问题:
"运维能搞" 和 "本来运维可以不用额外搞这个",前者更好吗?

参考我前面几楼说过的工程逻辑、跨工种跨部门甚至跨公司的观点
1 ... 35  36  37  38  39  40  41  42  43  44 ... 56  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3746 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 00:59 · PVG 08:59 · LAX 17:59 · JFK 20:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.