#145 楼 @ywjno 不过给你展示一下,sinatra 的作者最近在写 Go 的代码,https://github.com/bmizerany?tab=repositories 所以我们需要的是拥抱变化,Go 的并发比用 ruby 内部实现的多线程不知道简单多少
#145 楼 @ywjno 我没说 ruby 一定是性能差,robin 写的文章里面也分析了 rails 存在的问题:总之,无论是 Linkedin 的移动 API 网关还是 Iron.io 的后台任务系统,用 Ruby 来编写,本身并不是问题,实践也有大量案例证明使用 Goliath 或者 Sinatra 编写高性能 Web Service 都是可行的。问题只是在于我们应该:Ruby off rails 了。 http://robbinfan.com/blog/40/ruby-off-rails
#142 楼 @bhuztez 那些概念啊?我觉得一天应该可以了解基本了啊,你看浩哥写了两篇文章,我觉得你花个一下午应该就可以入门了:http://coolshell.cn/articles/8460.html http://coolshell.cn/articles/8489.html
#139 楼 @Numbcoder 我没有紧张,也没有态度不好,我一直都是这样直来直去的性格,也许说的过了,但是我觉得激烈的讨论很有帮助啊,我是很欢迎大家一起来挑刺,帮我找出各种问题,因为毕竟靠一个人做框架是做不好的,大家的力量才能做好。所以我很跑到这里来很乐意和大家一起来探讨。
针对性能对比的话,这个上面的对比性能确实是这样,而且你看我上面提的 iron 的例子,都是 ruby 迁移到 Go 的案例,我觉得没必要修改吧
#130 楼 @rasefon 还有我觉得 robbin 的这一篇博客,也详细分析了 ruby 存在问题,我觉得对于 rubyer 来说,应该挺适合的,http://robbinfan.com/blog/40/ruby-off-rails
#130 楼 @rasefon 下面这些摘抄自《http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html》 ,然后这一篇详细介绍了为什么设计 Go http://www.oschina.net/translate/go-at-google-language-design-in-the-service-of-software-engineering。
Go 中对 C 和 C++ 进行的重要简化的清单:
除了这个简化清单和一些未提及的琐碎内容,我相信,Go 相比 C 或者 C++ 是更加有表达力的。少既是多。
#128 楼 @rasefon 其实这个帖子也没有和 ruby 对比,但是你真要说和 ruby 对比,那 ruby 完全不能比,ruby 是动态语言,Go 是静态语言,所以不具有对比性,但是你可以了解一下 Go,用来开发 ruby 擅长的 Web 方面,也不输多少。下面这个是 ruby 迁移到 Go 的经典案例:
Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了连锁故障:http://www.infoq.com/cn/news/2013/03/ruby-to-go
#17 楼 @luikore #42 楼 @gihnius #40 楼 @reus #37 楼 @rasefon #15 楼 @bhuztez
谢谢各位的讨论,针对大家提出的一些意见,我努力改进了一下目前 beego 的 csrf 的做法
csrf 在表单中存的是一个随机字符串,cookie 采用了 GetSecureCookie 的方式,如下所示:
func (c *Controller) XsrfToken() string {
if c._xsrf_token == "" {
token, ok := c.GetSecureCookie(XSRFKEY, "_xsrf")
if !ok {
expire := 0
if c.XSRFExpire > 0 {
expire = c.XSRFExpire
} else {
expire = XSRFExpire
}
token = GetRandomString(15)
c.SetSecureCookie(XSRFKEY, "_xsrf", token, expire)
}
c._xsrf_token = token
}
return c._xsrf_token
}
至于@luikore 提出的 session 需要支持 https 的支持,目前已经增加额外的参数支持
#109 楼 @bhuztez https://github.com/astaxie/beego/pull/215/files 但是我觉得这个放的位置需要改进,还有一些实现的方式
#61 楼 @luikore 继续驳斥你各种观点:准确点说, 是这个框架没有签名 cookie 支持, 如果用了这个框架, cookie 就应该只用来存 session identifier 和存与用户身份不相干的信息. 使用时如果不知道这一点就很危险.
这一点的危险在哪里?为什么不能存类似 csrf 签名加密的 cookie,你目前的 cookie 存都是怎么做的,签名 cookie 我自己签名过了存不可以嘛?
另外就是你的 sessionid 不支持 secure (https only) 的设定, 利用 dns 污染进行 session hijack 也是可能的, 不适合用来做电子商务收钱等安全性要求比较高的网站.
这个功能可以加,而且不是那么难的事情,你不用说的好像很严重的 bug 问题。
如果服务器跑在 nginx 后面, 通过 tcp 连接信息得来的 ip 都是同样的, 如果用户用了代理, 看到的 remote ip 都是同样的.
你不了解 nginx 吧
按照你的计算方式, 相同 ip, 同一时间的请求, 就会存在 csrf token 撞车的情况. 然后攻击者使用某个流行的 proxy 去访问你的网站来获取一个 token, 那么通过这个 proxy 的用户都有比较大的机会和攻击者的 token 撞车, 攻击者在他的伪造表单里自动更新这个 token 坐等鱼上钩. 你最后就只能寄希望在 nanotime 上了.
双重的 unixNano 能冲突的概率几乎没有,但是你们说的通过 IP 来做 token 认证确实可以改进的更好,例如 uuid 之类的,这一块后期我可以改进
最后, 因为你没有防止篡改 cookie 的手段, 你的 csrf 不该放 cookie 而应该存在 session store 里 (你的情况就是 文件/数据库/redis/内存了), 或者继续把 csrf 放 cookie 里, 把签名附上也可以.
目前的 cookie 是已经签名加密的,用户篡改的话能通过认证嘛?csrf 不一定非得放 session 就是安全的。