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?

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'

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

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

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

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

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

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

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

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

哈哈，我顶你！别他妈在我面前谈你的理想。

试用期一个月一千？