graphql 非常考验设计能力（把 schema 设计好，剩下的就交给前端堆积木了），同样考验前端的自觉能力（用到什么字段取什么字段，千万别一股脑的把没用的也取了，那对于后端就是噩梦了）

设计推荐帖（https://ruby-china.org/topics/40695），翻译的挺好

简单，多给捧捧场，帮忙介绍介绍。 另外成功推荐有红包

希望大家多捧捧场，加微信，发邮箱都可以的。最迟当天回复！！！

虽然由于自身原因没有去这家公司，但是面试官很 nice，技术栈感觉挺好，老板逻辑清晰。最起码交谈后的印象是这样 。顶一下！！

请问，大专学历的考虑吗？

还有为了复用cache_key，为以后缓存优化做准备，引入了cache_key_with_version和cache_version，代码已修改

这个优化主要解决的就是，当集合数据没有变化的时候，不需要查询数据库。 你可以试一下你的 demo，即时集合数据中的数据没有任何变化，但是为了生成集合缓存键，他还会进行查询数据库。

怎么用？展示你的 code

应该不会，即使缓存失效，也只会查询一次数据库。 相交优化前，好很多，优化前不论数据是否修改每次都会查询数据库。

单人实在不能兼顾项目的速度和质量，只能发帖求助。@jdsh乍一看没认出来，简单师

新项目在用

看来遇到老人啦，现在主要是 PHP，但是新项目让我来搞，就用 Ruby 啦 ，时间紧只能那趁手的来。

自带点人气，好不容易来个 1 楼，怎么删除了 ！

觉着楼主记录最新的 session_id，行的通的。

通过旧的 session_id 找用户，这种后端主动登出，需要后端向前端交互，实时性高的话需要 websocket。

不过如果实时性要求不高的话，你可以通过在过滤器中判断只要与新的 session 不一致，就 sign_out，做这种被动处理。

发现

通过源码跟踪，最终找到 xml 实体解析类：REXML::Entity ，没有找到对外部实体的引入处理逻辑。
不考虑项目中猴子补丁因素的话，Hash.from_xml() 应该是没有 xxe 漏洞的。

# location: ruby/lib/rexml/entity.rb
def value
  if @value
    matches = @value.scan(PEREFERENCE_RE)
    rv = @value.clone
    if @parent
      sum = 0
      matches.each do |entity_reference|
        entity_value = @parent.entity( entity_reference[0] )
        if sum + entity_value.bytesize > Security.entity_expansion_text_limit
          raise "entity expansion has grown too large"
        else
          sum += entity_value.bytesize
        end
        rv.gsub!( /%#{entity_reference.join};/um, entity_value )
      end
    end
    return rv
  end
  nil
end

跟踪过程

ruby: 2.3.3
rails: 4.2.7.1

• ActiveSupport::XMLConverter
• ActiveSupport::XMLConverter
• ActiveSupport::XmlMini
• ActiveSupport::XmlMini_REXML
• REXML::Document
• ...
• REXML::Entity

本地验证了一下没有问题，好像 rails 已经帮我们处理。

xml_str = <<-END
<?xml version="1.0"?>
<!DOCTYPE test [
<!ENTITY writer "Bill Gates">
<!ENTITY copyright "Copyright W3School.com.cn">
<!ENTITY xxe SYSTEM "/Users/somebody/test.txt">
]>

<test>&writer;&copyright;&xxe;</test>
END

Hash.from_xml(xml_str)  # => {"test"=>"Bill GatesCopyright W3School.com.cn&xxe;"}

坐等其他发现 。

明白了 多谢。

应该理解的问题，感觉官网上说的应该就是您说的那样@w7938940

上传过程

1. 生成随机对称秘钥进行文件加密
2. 使用 rsa 对随机对称秘钥进行加密
3. 上传加密过的随机对称秘钥和文件

下载过程

1. 获取文件的加密的随机对称秘钥
2. 使用 rsa 进行解密对称秘钥，并使用它解密

以实际结果来看

应该是使用了 rsa 非对称加解密，解密速度确实很慢

不知道有没有其他人使用过 aws s3 的非对称解密，不想再看源代码。

直接设置一下 redis 中内容的有效期为 15 分钟，是不是更好一点？超过 15 分钟后，重新加载一下

#3 楼 @lyq 劳模一枚！已在拉勾相约！！

顶一下，实现有很多种方式，坚持使用更好的！

实战经验，手动点赞！！！

为教育投资