还未发布过话题
  • erlang 那种 umount 旧的 保持的老会话在旧实现里, 同时 mount 新的处理新的会话才能算热部署吧?

    php 生产环境依赖 php 的那种"热部署"简直在拷问自己的 RP,不仅修改多个物理文件之间不能保障原子性更新, 同时也无法保障 opcode cache 会同步更新 (看重性能的生产环境下启用各种 opcode cache 都是鼓励 never 刷新, 或者根据 ttl/访问计数刷新), 依赖语言特性的那种"热部署"每次修改前都得去烧柱香.

  • Rails 在高并发下的性价比 at 2015年11月10日

    改了语言不考虑改架构是耍流氓啊,也无非是把语言层先跑死换成后端数据库一类的服务先跑死.

  • 看见就不舒服的缩写 at 2015年10月27日

    缩写特定环境下能一眼看懂就好了, 以前 mozilla 负责 firefoxOS 相关的宫力博士现在自己搞的 firefoxOS 分支可实打实的叫 H5OS 啊, 要不去吊打他一下看看?

  • 关于加密和 URL 的冲突 at 2015年09月11日

    用 SSL 就不说了.

    建议隐藏的 form 自动 post 一下, 或者通过加自定义的 http token 字段. 业务上要是不能保障不会产生由用户引用的来自外站的资源, 如图片视频甚至外链, 在 URL 里直接带 token 或者 session id 都会有安全问题. 比如用户 img 自己网站一张图, 就可以去日志里数 referer 里的 token 了; 再比如用户 A 发了个自己网站的外链, B 点了, A 又可以去日志里看 referer 里的 token 了

  • 茴香豆有幾種寫法之 Loop at 2015年02月17日
    `seq 1 15`.split.map(&:to_i).each {|number| puts "The number inside the loop is #{number}" }
    

    😄 作弊的方法算不

  • #8 楼 @Los Martini 说明不了 Go 的性能, 这东西为了酷炫黑魔法用太多, 性能超烂, 甚至都被 PyPy 下的 tornado 甩老远,Martini 的作者都拆了一个叫 negroni 的 middleware 包, 然后自己跑去玩 mux 了.

  • #16 楼 @xds2000

    第一, 明确观点请用事实和代码说话, 用感觉说话会带来思维盲点的。

    我不再重复我在 15# 说的两个等同了, 事实上拿加密 cookie 作为默认 session 选项也不是 rails 一家异想天开弄出来的, 比如 php 的 codeigniter, java/scala 的 play, python 的 flask, go 的 gorilla 默认的 session 方案都是加密 cookie.

    淘宝分享用加密 cookie 作为 session 方案(请搜"淘宝 session 框架")已经实施了四五年了, 请问这几年出现的几次安全问题哪次和这方面有关?

    第二, 谁说服务端 session 就不需要验证 sign 了?

    比如,你用手机和电脑同时登录同一个账户, 分别是两个 session, 其中一个改了密码就必须让另一个失效对吧?

    你的方案是另外通过 sql db 或者 redis 的 set 维护 id 和 session 的对应表, 实现连锁销毁。

    但是正常的通用 session 方案里也是通过 current_user 的 password 和 token 做一次 hash, 和 session 里的 sign 验证一下来判断是否有效。

    一方面后者不用特意额外搞个 sql db 或者 redis set 维护变更,维护成本小, 二来也不需要重度依赖对应表, scale 成本也低。

  • #12 楼 @xds2000

    第一点不是很一致么 (1) 无论是 cookie store 还是传统的 cookie(session id)<->server session, 就算再通过 secret key 加密, 劫持到 cookie 时已经算完了, 这方面除了 ssl 是没办法保障的。 (2) 不考虑劫持现象, 传统的 cookie(session id)<->server session 无法伪造, 但是 cookie store 的 session 在服务端 secret key 不泄漏的情况下, 同样无法伪造。 所以安全系数上是完全一致的。

    第二点针对登出失效, 这是设计问题, 不是安全问题 cookie store 的 session 检测用户时同样需要存在一个 sign 做验证 (比如根据用户的密码和一个 token 字段), 用户登出完全可以重设生成这个 sign 所需要的 token, 也就是说当用户登出或者修改密码时,原先保存在 session 里的 sign 已经失效了, 当然也就未登录了。

  • #9 楼 @xds2000 服务端 session 也依赖 cookie, 劫持保存在客户端的 session id 照样能产生中间人攻击, 没区别, cookiestore 保存好 secret key 安全性不会比传统 session 差。 mysql 内存表坑很多, 比如不支持大字段, 就算是 varchar 照样按定长算,没特殊要求尽量别用这东西。