• I think it is not proper to only have the requirements. All the candidates care about what you can supply. Is there a compensation standards?

  • 分享 - JS - 函数中的 this at 2018年10月26日

    Thanks buddy

  • 你这个问题涉及的知识,值得分享下: 用303的原因是,默认的302或者301(永久跳转)是不会改变请求方法的,也就是你在发送DELETE请求的时候,如果是DELETE,那么跳转的时候还是会用DELETE,但是如果你想跳的是个页面那么明显需要用GET。这时候就需要用303,303就是为此而生。refer: https://zh.wikipedia.org/wiki/HTTP_303

    再说没刷新的问题:
    前端发送的请求有两种方式,浏览器发送或者JS发送。是浏览器发送的话,默认是会在新页面给你渲染的,所以肯定会刷新,即便你没有redirect,只是render。
    如果是JS发送的话,因为是异步的,所以是不会自己去刷新页面的,就需要你自己去刷新,通过更改window.location.href

  • 看起来确实很简洁,但是跟mvc的职责划分不太吻合。类似<model>_options这样的方法出现在helper中看起来更合理。

  • redirect_to :index ? 不应该是这样吗 redirect_to action: 'index'

  • Rails 中消失的 CSRF token at 2018年10月24日

    @ecloud 我想你表达的应该是在不同的浏览器窗口打开同一个web应用。 你的表述中有一个问题:

    当rails验证的时候会用最后产生的authenticity_token验证

    Rails并不是用最后一个生成的token,而且你不同的窗口中的打开的应用对应了不同的session,而session存了不同的token用于请求的验证。

  • Rails 中消失的 CSRF token at 2018年10月24日

    @warmwind 感觉你中间有一句话说得不够明确,会导致误解:

    “而server端就可以比较这两处的是否一致来做出判断,判断请求的来源是否可靠,” 「因为第三方是无法知道session中的token的」

    主要是最后一句 「因为第三方是无法知道session中的token的」。 第三方在这里应该指的是另外一个站点。这句话的陈述没错,一个不同的站点肯定不可能知道另外一个站点的session数据的。即使是同一个站点的frontend side也是没法知道本站点的session数据的。但是跟我们要想搞明白的 Rails CSRF的细节没关系。

    其实关键在于,发往服务器的请求中的token,要么是模版渲染的时候从session 中读取的,要么是JS从本站点的meta tag中读取的。那么对于第三方站点上的脚本,这其中的任何一个它都没法拿到,所以这样才防止了CSRF攻击。

  • 面试是这样的,运气成分很大。你不知道面你的人是个什么样的人。但是如果跟面你的人谈不拢最好不去了。毕竟跟一个谈不拢的人一起工作是很痛苦的

  • 哈哈,我顶你!别他妈在我面前谈你的理想。

  • 试用期一个月一千?