kayakjiang (jgm)

那种表名是业务 +日期的表你们会用 AR 去查询吗?

kayakjiang — Sat, 04 Jan 2020 00:09:48 +0800

我以前做的项目里有大量的这样的表 a_20120101, a_20120102, a_20120103, 简单来说表名就是 业务名_日期, 比如有统计用户佣金的表，统计用户等级的表，统计用户销售额的表等等，这些表加起来不下千个，这些表里的记录通过 user_id 和 users 表关联，这里不讨论这样的设计有没有问题，这已经是一个客观事实没办法改变了，现在的问题就是让大家实现这么一个功能：输入开始日期，结束日期，输入用户 id, 查询出这个用户在日期范围内所有的 a_ 相关的数据。我们当时解决这个问题的方法就是手写拼 sql, 确实有点痛苦，我后来实现过一个 sql builder 叫 sqlknit https://github.com/baya/sqlknit 去实现拼 sql 的功能，弄完以后发现还不如手写 sql. 你们会怎么做？最好给出代码。

相关的话题是这个，https://ruby-china.org/topics/39399

去他的 RTFM, 只要 @kayakjiang 我有问必答，绝不敷衍

kayakjiang — Mon, 29 Apr 2019 13:37:17 +0800

前几天和深圳一家用 ruby 的公司电话聊了将近一个小时，快结束时这家公司的负责人问我：你觉得 ruby 慢吗？我：不慢，rails 目前还是最好的 web 开发框架，绝大部分的性能问题都是数据库那边造成的。他又继续问：那为什么感觉国内 ruby 的开发者越来越少，想用 ruby 的公司也越来越少？我有点答不上来，只好说不是 ruby 语言本身的问题，至少我工作这么多年，还没有遇到哪怕一家公司是因为 ruby 的慢导致公司关门的。他赞同我的观点，瞬间有了种惺惺相惜的感觉，我估计他也是混 ruby-china 的，可惜不知道他在 ruby-china 的 id. 这几天我在思考他提的问题，我觉得 ruby 主要的问题是新人太少了，也许很多想进入 IT 领域的人根本不知道有 ruby? 也许我们的社区对新人还是不够友好？

RubyConf China

这个是含金量最高的推广了，虽然受众主要是业内人事，但是给了一个广阔明亮的场地，让大家相互了解下都在研究什么好玩的东西，一起搞搞事情，国内用 ruby 的公司也可以出来宣传下，但是非常可惜没有继续办下去。

李笑来的全栈营

这个全栈营对 rails 的推广效果其实很猛，就连我那位在长郡中学教书的大嫂当时都在转全栈营的学习课程，完全两个世界的人啊，要不是她的课比较紧张，估计都会打算学习下 rails 了。5 万块的价格可能有点贵，但我觉得是市场定价没有强买强卖，遗憾的是这个全栈营没有继续做下去。

我的有问必答

只要你 @kayakjiang 无论什么技术问题，我有问必答，我的回答会迟到，但是不会缺席，也绝不会用 RTFM 或者 google 来回应你，你不用考虑任何提问题的方法，步骤，也不用担心自己提的问题是不是太简单或者初级，just do it 只要把你的问题和疑惑贴上来并 @kayakjiang 就行了，唯一的要求是不要像这个人 https://ruby-china.org/EricWJP, 别骂人就行了，回答错了，讨论下指正下就好了。

RTFM[https://en.wikipedia.org/wiki/RTFM] 是 read the fucking manual 的意思，还有许多其它的变种，咱不和它们玩：

RTBM ("read the bloody manual") (In some countries, e.g., the UK and Australia, this is a fractionally more polite alternative with identical meaning[5])
RTFA ("read the fucking/featured article"—common on news forums such as Fark.com[6] and Slashdot, where using "TFA" instead of "the article" has become a meme)
RTDA ("read the damn article")
RTDM ("read the damn menu")
RTDM ("read the damn manual")
WABM ("write a better manual" – an answer complaining that the manual is not written well)[7]
RTFE ("read the fucking error")
RTFM41 ("read the fucking manual for once")
RTFW ("read the fucking wiki")
RTFC ("read the fucking chart" – a response that Physicians give to coders who submit inappropriate queries)
RTFS ("read the fucking source" or "read the fucking standard")[8]
RTFB ("read the fucking binary")[9]
RTFQ ("read the fucking question")

怎样在技术论坛里对技术问题进行高效沟通

kayakjiang — Mon, 14 Nov 2016 21:48:34 +0800

一年前我在这个坛子里写了一篇怎么用 Rails 写 API 的文章：https://ruby-china.org/topics/25822, 写这种入门的文章很费时费力，我要把自己放到一个新人的角度上去考虑很多问题，需要顾及很多细节，同时还要冒着被同行看穿底裤的危险:), 但是这篇文章收获了很多赞，也确实帮助了很多新人，这让我满足，直到现在还不时有人在那篇文章下问我一些问题，我很乐意帮忙解决这些问题，这些问题本来很简单，但是解决的过程很曲折，比如今天有位同学问了这样一个问题：

我第一眼看到这样的问题是懵圈的，没有日志，没有出错的信息，于是我不得不向这位同学请教出错的详细信息是什么，出错相关的日志在哪里，然后又是一阵折腾，最后终于解决问题。如果这位同学能够在提问的时候把错误详情，日志等信息一并提过来，这个问题估计一个来回就能解决了。

比如还有同学问我：

新人请教下 bundle exe 命令和 --no-assets 参数为何无法识别？本人 ruby 版本 2.2.4, rails 4.2

我的懒癌一发作，我是不想去请教到底报了什么出错信息。

还有同学说某个方法改进下可能会更好，但是这位同学就是不一次性告诉我该怎么改进，而我又实在是懒地打字去请教。

上面的这些问题如果是面对面交流，可能算不上问题，因为毕竟声速快，多动下嘴皮子也不累。

说了一些问题，我也举一些正面的例子：

对于这些同学提的建议和改进我除了感谢就是感动，因为他们提的建议和问题一目了然，不需要我多问，我直接去改就行了。

有些同学提的问题我没有回复，不是因为我对这些同学有什么意见，而是因为我懒癌一发作就不想多请教，多打字。

高效沟通的方法就是把对方看作一个随时会懒癌发作的人，把问题尽量描述清楚，把各种信息给足对方。

微信小程序开发和 Rails 开发的相似之处

kayakjiang — Wed, 09 Nov 2016 19:47:41 +0800

最近参照微信小程序的官方基础视觉样式库：https://github.com/weui/weui-design?t=20161107撸了一套微信小程序的 UI, 在练习的过程中体会到微信小程序开发和 Rails 开发有不少相似之处。

微信小程序和 Rails 程序的相似之处

Rails 程序

在 Rails 程序中，客户端的请求 (request) 会到达对应的 Controller 实例，然后由这个 Controller 实例中的对应的 action 来处理请求，处理后的数据会通过 render 方法响应给客户端。

微信小程序

在微信小程序中，View 对象发送事件 (event) 到对应的 Page 对象中，然后由这个 Page 对象中的对应的 event_handler 来处理事件，处理后的数据会通过 setData 方法响应给 View对象。

微信小程序练习预览

代码在 https://github.com/baya/weui-base-guide-practice, 一共有 36 个页面，欢迎下载玩耍。

首页：

表单错误页面：

列表页面：

搜索中页面：

35 * 2 = 70

kayakjiang — Wed, 09 Nov 2016 13:04:54 +0800

已经解决

Web 安全和 Rails

kayakjiang — Tue, 20 Sep 2016 20:34:07 +0800

这几天遇到一些涉及 web 安全的问题，然后在自己的博客中翻到了这篇两年前的文章，觉得有不错的参考价值，在阅读过程中，我不断的在想外面的世界这么精彩，写这篇文章的家伙为什么会窝在自己的电脑前没日没夜的做试验，写这么长的一篇东西，这也许就是程序员的一种原始的创作欲望吧。文章比较长，demo: https://github.com/baya/websafe 代码可能更适合阅读。

本文主要描述了 XSS， CSRF， Session Fixation 和 Brute Force 等四种威胁 WEB 安全的攻击手段的概念原理以及相关预防方法。对于怎么预防 XSS 攻击，本文给出了九种方法，比如 HTML Escape Before Inserting Untrusted Data into HTML Element Content 等，并结合 rails 对各种预防方法进行了一系列试验，尤其是对 HTTPOnly 和 Content Security Policy 两种方法不厌其烦地进行了十次试验。同样对于怎么防御 CSRF攻击，本文从其原理着手，结合 rails 进行了一系列有针对性的攻防试验，以帮助我们理解 CSRF 攻击的原理并积累预防 CSRF 攻击的经验。

平时开发项目时会注意一些比较基本的安全问题，比如数据库里不能用明文保存密码，线上日志过滤掉密码等敏感信息，把任何来自用户的数据看作不安全数据，防止 SQL 注入，防止用户在网页上运行脚本等。我想现在是时候开始对 WEB 安全方面的知识做一个比较系统的学习了，那就从 XSS, CSRF, Session Fixation, Brute Force Attack 等开始吧。

XSS

XSS 全称 Cross Site Scripting 即跨站点脚本攻击, 本来 Cross Site Scripting 的缩写应该是 CSS, 但是 CSS 在开发者心中早已经根深蒂固地表示为 Cascading Style Sheet 即层叠样式表的缩写了，还好 Cross 有十字架的意思，而 X 这个字母又像十字架，所以 XSS 这个缩写在某种意义上来说是非常贴近原意的。

XSS 简单的来说就是在那些本身善良，受信任的目标网站上注入恶意代码，通过这些恶意代码，攻击者可以实施盗取用户数据，盗取用户的 session 等等危害行为。那攻击者是怎么注入恶意代码的呢？一个应用或多或少需要接收用户输入的数据，同时如果你的应用在输出用户数据时没有对它们进行验证或者编码或者采取的相关措施不够仔细严格，那么就会给攻击者以可乘之机，攻击者会在很多让你意想不到的地方向你的应用注入恶意代码。

见招拆招

这些招数来自于 https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet, 为方便以后查阅，我根据自己的理解对其作了一些试验和梳理：

招数#0 Never Insert Untrusted Data Except in Allowed Locations

这招非常狠，我根本不让你插入任何我不信任的数据，纵你再狡猾你也无法对我发起 XSS 攻击了，这就像把电脑网线拔掉来阻止电脑被黑一样。比如在下面的地方，我们不放任何不可信数据：


任何 HTML 元素里 <body>...不放不可信数据..</body>

script 标签里 <script>...不放不可信数据..</script>

HTML 注释里 <!--...不放不可信数据...-->

元素的属性名称里 <div ...不放不可信数据...=test />

标签名称里 <不放不可信数据 ... href="/test" />

CSS 里 <style>...不放不可信数据 ...</style>

如前面所说这招杀伤力过大，如果死板执行的话，会导致我们的应用基本不可用，但是招数#0的最重要的意义是提醒我们插入任何用户数据之前请三思：必须插入这种数据吗？这种数据可信吗？若不可信，怎么让它变的可信或者至少无害呢？后面的 1-5 招都是在这一基础上进行的：如果我们要插入不可信的数据，那么我们必须让这些不可信数据至少变得无害。为了方便后面的试验，我建立了一个叫 websafe 的 Rails 项目，代码在此：websafe，后面的所有试验如果没有特殊说明，都是在此项目里进行的。

招数#1 HTML Escape Before Inserting Untrusted Data into HTML Element Content

HTML 转义一般来说是进行下面的一些操作，从而阻止可执行内容的产生。

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;
/ --> &#x2F;

我们看一段 erb 代码，

<h2>Html Escape</h2>
<p class="dangerous"><%=raw @evil_user_data %></p>
<p class="safe"><%=h @evil_user_data %></p>
<p class="safe"><%= @evil_user_data %></p>

其中 p.dangerous 是危险的，因为它输出的是原始的用户数据，p.safe 是安全的因为它对用户数据进行了 HTML 转义，如果

@evil_user_data = 'alert("see you")'

那么 p.dangerous 会导致浏览器执行 alert("see you"), p.safe 则会包含一个经过转义的无害的数据：

早期 Rails 的版本中 <%= @evil_user_data %> 等价于 <%=raw @evil_user_data %>，我们必须显示的使用 h 方法进行 HTML 转义才能达到安全的目的，不过现在的 rails 已经改正了这一做法，现在 <%= @evil_user_data %> 和 <%=h @evil_user_data %> 是等价的，也就是说在现代的 Rails 中只要我们不显式的去调用 raw，Rails 能够帮助我们做好 HTML Escape 这一工作的。

招数#2 Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

首先我们做一个试验，控制器代码，


class AttributeEscapeController < ApplicationController

  def index
    @evil_user_data = "\"><script>alert(\"XSS\")</script><\""
    @evil_user_data_2 = "\"\"><script>alert(\"XSS\")</script><\"\""
    @evil_user_data_3 = "javascript:var a='XSS'; alert(a)"
  end

end

模板代码，

<h2>Attribute Escape</h2>
<p class="dangerous1" value="<%=raw @evil_user_data %>">Hello Danger</p>
<p class="dangerous2" value=<%=raw @evil_user_data_2 %>>Hello Danger</p>
<a class="dangerous3" href="<%=h @evil_user_data_3 %>">XSS</a> <br/>
<p class="safe" value="<%=h @evil_user_data %>">Hello Safe</p>
<p class="safe" value="<%= @evil_user_data %>">Hello Safe</p>

p.dangerous1, p.dangerous2 和 a.dangerous3 会被恶意数据侵入，变成：

<p class="dangerous" value=""><script>alert("see you")</script>&lt;""&gt;Hello Danger</p>
<p class="dangerous" value=""><script>alert("see you")</script>&lt;""&gt;Hello Danger</p>
<a class="dangerous3" href="javascript:var a='XSS'; alert(a)">XSS</a>

注意 a.dangerous3 仅通过 h 方法还是不够的，我们需要去掉 'javascript' 这种能够引起恶意代码执行的字符串，所以我们有 a.safe2,

<a class="safe2" href="<%=h @evil_user_data_3.gsub('javascript', '') %>">Hello Safe</a> <br/>

招数#3 JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values

当我们需要在 JavaScript 代码里插入用户数据时，我们需要进行 JavaScript Escape, 现在我们进行一次 XSS 攻击试验，

控制器代码，

class JsEscapeController < ApplicationController

  def index
    @evil_user_data = "\";alert(\"XSS\");//"
  end

end

模板代码，

<h2>Js Escape</h2>
<script>
  var user_dangerous = "<%=raw @evil_user_data %>";
  var user_safe1 = "<%=h @evil_user_data %>";
  var user_safe2 = "<%= @evil_user_data %>";
  var user_safe3 = "<%= escape_javascript @evil_user_data %>";
  var user_safe4 = <%=raw @evil_user_data1.to_json %>;
</script>

user_dangerous 会引入 XSS 攻击，它会变成：

var user_dangerous = "";alert("XSS");//";

user_safe1, user_safe2, user_safe3, user_safe4 虽然可能导致数据不正确，但至少都是安全的。

招数#3.1 HTML escape JSON values in an HTML context and read the data with JSON.parse

基于这一方法，如果我们需要响应浏览器 JSON 数据，那么我们应该保证响应头的 Content-Type 为 application/json 而不是 text/html, 否则浏览器会直接执行响应报文里地 javascript 代码。试验如下，

控制器代码：

class JsonEscapeController < ApplicationController

  def index
    @evil_user_data = "{\"Message\":\"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
   =The+Gardens<script>alert(XSS)</script>&AddressLine2=foxlodge+woods&TownName=Meath'.\",\"MessageDetail\":\"No type was found
   that matches the controller named 'pay'.\"}"

    render text: @evil_user_data
  end

end

响应为：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
   =The+Gardens<script>alert('XSS')</script>&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
   that matches the controller named 'pay'."}

这种响应会导致浏览器执行代码 alert('XSS'), 也就是说我们的应用被 XSS 了。但是如果我们将响应头的 Content-Type 设置为 application/json 就可以避免这种侵入，在 Rails 中可以像下面这样做：

class JsonEscapeController < ApplicationController

  def index
    @evil_user_data = "{\"Message\":\"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
   =The+Gardens<script>alert(XSS)</script>&AddressLine2=foxlodge+woods&TownName=Meath'.\",\"MessageDetail\":\"No type was found
   that matches the controller named 'pay'.\"}"

    render json: @evil_user_data.to_json
  end

end

此时响应为：

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

"{\"Message\":\"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9\u0026AddressLine\n   =The+Gardens\u003cscript\u003ealert('XSS')\u003c/script\u003e\u0026AddressLine2=foxlodge+woods\u0026TownName=Meath'.\",\"MessageDetail\":\"No type was found\n   that matches the controller named 'pay'.\"}"

招数#4 CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values

往 HTML 样式的属性里插入不可信数据时需要进行 CSS Escape 并且对数据进行严格校验，比如 URLs 只能以 "http"开头而不是"javascript"，同时各属性值永远不要以 "expression" 开头。原文中给了两个例子：

{ background-url : "javascript:alert(1)"; }  // and all other URLs
{ text-size: "expression(alert('XSS'))"; }   // only in IE

第一个例子在 chrome 和 safari 浏览器里做过测试，不会引导致 XSS，应该是现代的浏览器已经把这个漏洞堵住了。第二个例子，没有 IE 就没试验了。

招数#5 URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

向 HTML URL 的参数里插入不可信数据之前，需要对不可信数据做 URL Escape。在 Rails 里可以通过 CGI.escape 或者 URI.encode 做这个工作。

招数#6 Sanitize HTML Markup with a Library Designed for the Job

在 Rails 中可以使用方法 sanitize 做这方面的工作。sanitize 使用白名单制度，只有被允许的标签和属性才能作为可信数据插入到页面中。

招数#7 Prevent DOM-based XSS

DOM-based XSS 就是在操作 DOM 环境时向受害者的浏览器注入恶意代码。文中给出了一个攻击例子，

Select your language:
<select><script>
document.write("<OPTION value=2>English</OPTION>");
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
</script></select>

在我的试验中，预想访问 http://localhost:3000/dom_base_xss?default=<script>alert('XSS')</script> 会生成恶意代码：

<script>alert('XSS')</script>

但是浏览器会自动把 <script>alert('XSS')</script> 转义为 "%3Cscript%3Ealert(%27xss%27)%3C/script%3E", 所以试验没有成功，但是我们还是需要在 DOM-based XSS 这方面引起重视，毕竟道高一尺，魔高一丈。

在 HTTP 的 Set-Cookie 响应头里增加一个 HTTPOnly 标识就可以使用 HTTPOnly cookie 了，当然必须浏览器支持，否则浏览器会忽略此标识，如果浏览器支持 HTTPOnly 标识，那么客户端的代码就无法访问到这些受到保护的 cookie。我觉得这是一个非常有用的功能，这样即使站点被 XSS 污染，攻击者也拿不到 cookie 这类非常重要的数据，从而能最大程度地减少站点和用户的损失。现在我们用一个实际例子来试验设置 HTTPOnly cookie flag。

控制器代码：


class HttponlyFlagController < ApplicationController

  def true
    cookies["user_name"] = { value: "david", httponly: true }
  end

  def false
    cookies["user_name"] = { value: "david", httponly: false }
  end

end

httponly_flag/true.html.erb


<h2>HTTPOnly True</h2>
<script>
  alert(getCookie('user_name'));

  function getCookie(c_name)
{
if (document.cookie.length>0)
  {
  c_start=document.cookie.indexOf(c_name + "=")
  if (c_start!=-1)
    {
    c_start=c_start + c_name.length+1
    c_end=document.cookie.indexOf(";",c_start)
    if (c_end==-1) c_end=document.cookie.length
    return unescape(document.cookie.substring(c_start,c_end))
    }
  }
return ""
}

</script>

设置 HTTPOnly flag 时，其试验结果如下图所示：

我们看到 cookies["user_name"] 受到保护，客户端无法访问到 cookies["user_name"]。

httponly_flag/false.html.erb

<h2>HTTPOnly False</h2>
<script>
  alert(getCookie('admin_name'));

 function getCookie(c_name)
{
if (document.cookie.length>0)
  {
  c_start=document.cookie.indexOf(c_name + "=")
  if (c_start!=-1)
    {
    c_start=c_start + c_name.length+1
    c_end=document.cookie.indexOf(";",c_start)
    if (c_end==-1) c_end=document.cookie.length
    return unescape(document.cookie.substring(c_start,c_end))
    }
  }
return ""
}
</script>

未设置 HTTPOnly flag 时，试验结果如下图所示，

我们看到客户端此时可以访问 cookies["admin_name"]。

我们再看看 cookies['user_name'] 和 cookies['admin_name'] 的属性，注意看最后一条属性：'脚本可访问'

cookies['user_name']:

名字：   user_name

内容：   david

域：  localhost

路径：   /

发送用途： 各种连接

脚本可访问：  否（仅 Http）

cookies['admin_name']:

名字：   admin_name

内容：   jim

域：  localhost

路径：   /

发送用途： 各种连接

脚本可访问：  是

加强版招数#2 Implement Content Security Policy

Web 世界在经历 XSS 这个魔鬼多年的折磨和迫害之后， CSP 的出现可以说是大势所趋，民心所向。CSP 之前的各种抵抗 XSS 的方案虽然有效果，并且广泛使用，但是这些方案无论从哪个角度来看都像是在缝缝补补，并且在 XSS 疯狂的攻击下疲于应付，始终摆脱不了道高一尺，魔高一仗的咒语。而 CSP 的出现，让我们终于拥有了强大而系统化的武器去抗击 XSS 的侵害。

在响应头 Content-Security-Policy 里添加一些 CSP 相关的指令就可以实现 CSP 了，有些浏览器支持 X-WebKit-CSP 或者 X-Content-Security-Policy, 不过向前看，现代的浏览器都会支持 Content-Security-Policy 头，而忽略掉那些带前缀的 CSP 头，所以我们应该使用 Content-Security-Policy 头，在这里我们的 CSP 头如无说明即指 Content-Security-Policy 头。CSP 在控制页面加载资源的粒度上为我们开发者提供了丰富的指令，我们可以先快速了解下这些指令：

default-src, 用于为其他指令配置一个默认的资源列表;
script-src, 用于约束受保护的资源可以执行哪些脚本;
object-src, 用于约束受保护的资源可以从哪些地方加载插件;
style-src, 用于约束受保护的资源可以应用哪些样式;
img-src, 用于约束受保护的资源可以从哪些地方加载图片;
media-src, 用于约束受保护的资源可以从哪些地方加载视频和声频;
frame-src, 用于约束受保护的资源可以从哪些地方嵌入帧 (frame);
font-src, 用于约束受保护的资源可以从哪些地方加载字体;
connect-src, 用于约束受保护的资源可以使用脚本交互的方式 (比如 XMLHttpRequest, WebSocket, EventSource) 打开哪些 URI;

如我们前面所看到的，XSS 攻击最主要的威胁来自于内联脚本的嵌入，所以我们着重研究下指令 script-src, 并做一系列和 script-src 指令有关的试验，在试验之前我们需要说明两点：

CSP 指令基于白名单，也就是说只有匹配的资源才会允许加载，执行;
CSP 指令之间用 ";" 号分开，指令的值用空格分开，比如，

Content-Security-Policy: script-src self https://apis.google.com; report-uri /my_csp_report_parser;

在试验之前我们认识一个新指令：report-uri, 这个指令的作用是指定一个 URI, 当用户代理发现有违背 CSP 的事件时就会向这个 URI 发送报告。

测试环境：Rails-4.1.5, Chrome38, 为了能够接收到浏览器发送的 CSP 违规报告，我们的每一次试验都会设置 report-uri 为：'/csp_report'。

与 '/csp_report' 对应的控制器是 CspReportController, 在此控制器里我们会打印出 CSP 违规报告，控制器的代码如下：


class CspReportController < ApplicationController

  skip_before_filter :verify_authenticity_token

  def create
    Rails.logger.info "received csp report: #{pp JSON.parse(request.raw_post)}"

    render text: 'ok'
  end

end

试验一 `script-src 'none'`

'none' 的意思是禁止加载任何脚本，无论此脚本来自本站还是外站，也不允许执行任何内联脚本。

控制器内容：


class Csp::ScriptSrcController < ApplicationController

  def none
    set_csp "script-src 'none'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：

<h2>CSP: script-src 'none'</h2>
<%= javascript_include_tag "//upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js" %>

<script>
 alert("I will be disabled by csp");
</script>

试验的结果是，

'http://localhost:3000/assets/application.js' 被阻止加载;
'http://upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js' 被阻止加载;
内联脚本被阻止执行;

我们可以通过 Chrome 的终端查看这个结果，

同时我们可以在 '/csp_report' 后台看到相关的 CSP 违规报告，如下所示，

加载 'http://localhost:3000/assets/application.js' 时触发的违规报告：

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/none",
   "referrer"=>"",
   "violated-directive"=>"script-src 'none'",
   "original-policy"=>"script-src 'none'; report-uri /csp_report",
   "blocked-uri"=>"http://localhost:3000/assets/application.js",
   "status-code"=>200}}

我们注意到 "blocked-uri"=>"http://localhost:3000/assets/application.js", 即来自 "http://localhost:3000/assets/application.js" 的脚本资源被阻止加载。

加载 'http://upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js' 时触发的违规报告：

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/none",
   "referrer"=>"",
   "violated-directive"=>"script-src 'none'",
   "original-policy"=>"script-src 'none'; report-uri /csp_report",
   "blocked-uri"=>"http://upcdn.b0.upaiyun.com",
   "status-code"=>200}}

我们注意到 "blocked-uri"=>"http://upcdn.b0.upaiyun.com", 即来自 "upcdn.b0.upaiyun.com" 的脚本资源被阻止加载。

执行内联脚本时触发的违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/none",
   "referrer"=>"",
   "violated-directive"=>"script-src 'none'",
   "original-policy"=>"script-src 'none'; report-uri /csp_report",
   "blocked-uri"=>"",
   "status-code"=>200}}

试验二 `script-src 'self'`

'self' 表示允许加载同源的脚本，不允许加载不同源的脚本，不允许执行内联脚本。

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def self
    set_csp "script-src 'self'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：

<h2>CSP: script-src 'self'</h2>
<%= javascript_include_tag "//upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js" %>

<script>
 alert("I will be disabled by csp");
</script>

试验的结果是，

'http://localhost:3000/assets/application.js' 可以正常加载;
'http://upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js' 被阻止加载;
内联脚本被阻止执行;

相关 CSP 违规报告如下所示，

加载 'http://upcdn.b0.upaiyun.com/libs/jquery/jquery-2.0.3.min.js' 时触发的违规报告：

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/self",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self'",
   "original-policy"=>"script-src 'self'; report-uri /csp_report",
   "blocked-uri"=>"http://upcdn.b0.upaiyun.com",
   "status-code"=>200}}

执行内联脚本时触发的违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/self",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self'",
   "original-policy"=>"script-src 'self'; report-uri /csp_report",
   "blocked-uri"=>"",
   "status-code"=>200}}

试验三 `script-src 'self' ${EXTERNAL-SCRIPT-LIST}`

既可以加载同源脚本，也可以加载外部的与资源列表相匹配的脚本，但是不允许执行内联脚本。

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def self_ext
    set_csp "script-src 'self' http://example.com *.google.com"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：


<h2>CSP: script-src 'self external'</h2>
<%= javascript_include_tag "//example.com/a1.js"%>
<%= javascript_include_tag "//example.com/a2.js"%>
<%= javascript_include_tag "//evil.example.com/b1.js"%>
<%= javascript_include_tag "//apis.google.com/d1.js"%>
<%= javascript_include_tag "//apis.google.com/d2.js"%>
<%= javascript_include_tag "//apis.google.com/d3.js"%>

<script>
 alert("I will be disabled by csp");
</script>

我们可以通过 Chrome 的 console 查看试验结果，

试验结果：

'http://localhost:3000/assets/application.js' 匹配 'self', 浏览器会对正常请求此脚本。
'http://example.com/a1.js', 'http://example.com/a2.js' 匹配 'http://example.com', 浏览器会正常请求这些脚本。
'http://evil.example.com/b1.js', 不匹配任何 script-src 指令，浏览器拒绝请求此脚本
'https://plus.google.com/d1.js', 'https://plus.google.com/d2.js' 和 'https://plus.google.com/d3.js' 匹配 '*.google.com', 浏览器正常请求这些脚本。
内联脚本不匹配任何 script-src 指令，浏览器拒绝执行内联脚本。

CSP 违规报告：

加载 'http://evil.example.com/b1.js' 触发的违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/self-ext",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' http://example.com *.google.com",
   "original-policy"=>
    "script-src 'self' http://example.com *.google.com; report-uri /csp_report",
   "blocked-uri"=>"http://evil.example.com",
   "status-code"=>200}}

执行内联脚本时触发的违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/self-ext",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' http://example.com *.google.com",
   "original-policy"=>
    "script-src 'self' http://example.com *.google.com; report-uri /csp_report",
   "blocked-uri"=>"",
   "status-code"=>200}}

试验四 `script-src 'self' 'nonce-$RANDOM'`

阻止内联脚本的执行能够很大程度上减轻 XSS 对站点的攻击，但是完全阻止执行内联脚本也是很困难或者说不现实的，所以 script-src 指令引入了 nonce 值，通过设置 nonce 值，我们可以指定我们认为安全的内联脚本被允许执行。

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def self_nonce
    @rand = SecureRandom.hex
    set_csp "script-src 'self' 'nonce-#{@rand}'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：


<h2>CSP: script-src 'self-nonce'</h2>

<script class="blocked">
 alert("I will be blocked by csp");
</script>

<script class="blocked" nonce="123">
 alert("I will be blocked by csp");
</script>

<script class="allowed" nonce="<%= @rand %>">
  alert("Allowed because nonce is valid.")
</script>

我们可以通过 Chrome 终端查看试验结果，

试验结果：

script.blocked 都会被阻止执行，第二个 script.blocked 虽然有 nonce 值，但是与服务器生成的 nonce 值不匹配，所以仍然会被阻止执行。
script.allowed 被允许执行
'http://localhost:3000/assets/application.js' 匹配 'self', 浏览器会对正常请求此脚本。

CSP 违规报告：

script.blocked 触发了两次，但是只生成了一份违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/self-nonce",
   "referrer"=>"",
   "violated-directive"=>
    "script-src 'self' 'nonce-ca36b262e9019c9e320ac0628f0fa727'",
   "original-policy"=>
    "script-src 'self' 'nonce-ca36b262e9019c9e320ac0628f0fa727'; report-uri /csp_report",
   "blocked-uri"=>"",
   "status-code"=>200}}

试验五 `script-src 'unsafe-inline'`

'unsafe-inline' 匹配内联脚本，即允许执行内联脚本，即使允许执行，也通过 unsafe 提醒开发者内联脚本是不安全的。

与 'nonce' 可以指定某一块的内联脚本允许执行不同，'unsafe-inline' 可以让整个页面的内联脚本被允许执行。

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def unsafe_inline
    set_csp "script-src 'unsafe-inline'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：


<h2>CSP: script-src 'unsafe-inline'</h2>

<script class="allowed">
 alert("I be allowed by 'unsafe-inline'");
</script>

试验结果：

script.allowed 匹配 'unsafe-inline'，被允许执行;
'http://localhost:3000/assets/application.js' 被阻止加载;

CSP 违规报告：

加载 'http://localhost:3000/assets/application.js' 触发违规报告，

"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/unsafe-inline",
   "referrer"=>"",
   "violated-directive"=>"script-src 'unsafe-inline'",
   "original-policy"=>"script-src 'unsafe-inline'; report-uri /csp_report",
   "blocked-uri"=>"http://localhost:3000/assets/application.js",
   "status-code"=>200}}

试验六 `default-src 'self'`

如果没有指定 script-src, 浏览器会使用 default-src 'self' 进行匹配。

在试验六我们看到加载 'http://localhost:3000/assets/application.js' 会触发违规报告，于是我们想通过设置 default-src 'self', 试验能否加载 'http://localhost:3000/assets/application.js'

我们先做第一个试验，只设置 default-src 'self', 而不设置 script-src,

控制器内容：


class Csp::DefaultSrcController < ApplicationController

  def self
    set_csp "default-src 'self'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end


end

视图内容：

<h2>CSP: default-src 'self'</h2>
<%= javascript_include_tag "//evil.example.com/b1.js"%>

<script class="blocked">
 alert("I will be blocked by csp");
</script>

试验结果：

'http://evil.example.com/b1.js' 被阻止加载;
script.blocked 被阻止执行;
'http://localhost:3000/assets/application.js' 可以被正常加载；

第二个试验，设置 default-src 'self'; script-src 'unsafe-inline'',

控制器内容：


class Csp::MiscController < ApplicationController

  def default_script_src
    set_csp "default-src 'self'; script-src 'unsafe-inline'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：


<h2>CSP: default-src 'self'; script-src 'unsafe-inline'</h2>

<script class="allowed">
 alert("I be allowed by 'unsafe-inline'");
</script>

试验结果，

'http://localhost:3000/assets/application.js' 不被允许加载，即使设置了 default-src 'self', 这说明一旦设置了 script-src 的值，default-src 设置的值对 script-src 会失效;
script.allowed 允许执行；

试验七 `script-src 'unsafe-eval'`

一些侵入的文本可以把 eval(), new Function(), setTimeout([string], ...), and setInterval([string], ...) 等作为载体执行一些恶意任务，首先我们试验下 CSP 是否是默认阻止这些载体的，

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def block_unsafe_eval
    set_csp "script-src 'unsafe-iinline'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：

<h2>CSP: script-src 'block unsafe-eval'</h2>

<script class="allowed">

 eval("alert('XSS')");

</script>

<script class="allowed">
 setTimeout("document.querySelector('a').style.display = 'none';", 10);
 setInterval("clock()",50);
 var myFunction = new Function("a", "b", "return a * b");
 function clock() {
 };
</script>

试验结果：

我们看到 eval, setTimeout, setInterval, new Function() 都被阻止执行了。

CSP 违规报告，

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' 'unsafe-inline'",
   "original-policy"=>
    "script-src 'self' 'unsafe-inline'; report-uri /csp_report",
   "blocked-uri"=>"",
   "source-file"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "line-number"=>16,
   "column-number"=>2,
   "status-code"=>200}}


{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' 'unsafe-inline'",
   "original-policy"=>
    "script-src 'self' 'unsafe-inline'; report-uri /csp_report",
   "blocked-uri"=>"",
   "source-file"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "line-number"=>21,
   "column-number"=>2,
   "status-code"=>200}}

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' 'unsafe-inline'",
   "original-policy"=>
    "script-src 'self' 'unsafe-inline'; report-uri /csp_report",
   "blocked-uri"=>"",
   "source-file"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "line-number"=>23,
   "column-number"=>19,
   "status-code"=>200}}


{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self' 'unsafe-inline'",
   "original-policy"=>
    "script-src 'self' 'unsafe-inline'; report-uri /csp_report",
   "blocked-uri"=>"",
   "source-file"=>"http://localhost:3000/csp/script-src/block-unsafe-eval",
   "line-number"=>22,
   "column-number"=>2,
   "status-code"=>200}}

报告中通过 'line-number', 'column-number' 帮我们指出了违规处的具体的行号和列号。

如果我们需要在脚本中执行 eval(), new Function(), setTimeout([string], ...), and setInterval([string], ...) 等方法，那么我们可以设置 script-src 'unsafe-eval''，现在我们再做一个试验，

控制器内容：

class Csp::ScriptSrcController < ApplicationController

  def unsafe_eval
    set_csp "script-src 'self' 'unsafe-inline' 'unsafe-eval'"
  end

  private

  def set_csp csp_str
    response.headers['Content-Security-Policy'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：

<h2>CSP: script-src 'unsafe-eval'</h2>

<script class="allowed">

 eval("alert('XSS')");

</script>

<script class="allowed">
 setTimeout("document.querySelector('a').style.display = 'none';", 10);
 setInterval("clock()",50);
 var myFunction = new Function("a", "b", "return a * b");
 function clock() {
 };
</script>

试验结果：

我们看到 eval(), new Function(), setTimeout([string], ...), and setInterval([string], ...) 等方法可以执行，后台也没有收到任何违规报告。

试验八 `Content-Security-Policy-Report-Only: default-src 'self'`

如果你对 CSP 不够熟悉，那么在开始应用 CSP 时很可能会出问题，并且造成站点的可用性大打折扣，前期我们可以使用 Content-Security-Policy-Report-Only 代替

Content-Security-Policy, 这样浏览器不会阻止哪些违规的资源，但是会将违规报告发到我们指定的接收地址，这样有助于我们监控哪些地方可能会受到 XSS攻击，并采取适当的措施增强应用安全。现在我们来做一个试验来熟悉 Content-Security-Policy-Report-Only 的工作机制。

控制器内容：


class Csp::ReportOnlyController < ApplicationController

  def index
    set_csp_report_only "script-src 'self'"
  end

  private

  def set_csp_report_only csp_str
    response.headers['Content-Security-Policy-Report-Only'] = csp_str << "; report-uri /csp_report"
  end

end

视图内容：


<h2>CSP-Report-Only: Index</h2>

<%= javascript_include_tag "//evil.example.com/a1.js"%>

<script>
 alert("I should be blocked by csp");
</script>

试验结果：

我们可以到虽然浏览器识别出了违规的地方，但是并没有阻止它们继续执行，同时我们可以收到违规报告，


{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/report-only",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self'",
   "original-policy"=>"script-src 'self'; report-uri /csp_report",
   "blocked-uri"=>"http://evil.example.com",
   "status-code"=>200}}

{"csp-report"=>
  {"document-uri"=>"http://localhost:3000/csp/report-only",
   "referrer"=>"",
   "violated-directive"=>"script-src 'self'",
   "original-policy"=>"script-src 'self'; report-uri /csp_report",
   "blocked-uri"=>"",
   "status-code"=>200}}

现在可以对预防 XSS 攻击做一个小结了，

如果是 rails 的项目，在视图中慎重使用 raw 方法能够防止大部分的恶意代码侵入页面;
尽可能地使用 HTTPOnly 头，保住底裤；
鼓励用户使用现代化的浏览器特别是支持 Content-Security-Policy 的浏览器，并且我们自己也尽最大努力提供合适的 Content-Security-Policy;
对自己的站点多做些 XSS 攻击，争取在攻击者之前发现漏洞；

CSRF

CSRF 全称 Cross-Site Request Forgery, 意思是跨站点请求伪造。CSRF 的攻击原理比较好理解，比如我在站点 A 登录过了，然后我用同一个浏览器去访问站点 B 的某个页面，很不幸，此页面上被某些攻击者添加了一些恶意代码或者链接，如果我在 A 上的会话 (session) 没有过期，那么这些恶意代码或者链接就可能以我的名义绕过认证去作一些恶意的操作等。CSRF 攻击的过程大致如下图所示，

通过实际的动手操作，能够加深我们对概念的理解，所以我觉得很有必要自己动手模拟下 CSRF 的攻防，现在我们开始

模拟 CSRF 攻防

试验环境：

操作系统：Mac OSX
服务器：Pow
rails-4.1.5
浏览器：Chrome

使用 Pow 是为了可以使用类似于 webapp1.dev, webaap2.dev 的域名访问本地应用，详细的介绍可以参考: Pow 用户手册

首先建立两个站点，一个用作被攻击的站点：V, 另外一个用作发起攻击的站点 A, 为此我们将 websafe 这个项目分别拷贝为 'websafe-csrf-victim' 和 'websafe-csrf-attacker'


cd ~/workspace
cp -r websafe websafe-csrf-victim
cp -r websafe websafe-csrf-attacker

$ cd ~/.pow
ln -s ~/workspace/websafe-csrf-victim
ln -s ~/workspace/websafe-csrf-attacker

此时我们就已经建立好了两个用于试验的站点了。

用例 1

站点 V(在此试验中可以通过 'websafe-csrf-victim.dev' 访问站点 V, 在后面的描述中，站点 V 即代表 'websafe-csrf-victim.dev'), 有一个地址：'/csrf/admin/admin_user/unsafe_create' 可以用于创建管理员，访问此地址的请求目前是支持 GET 方法的，比如可以 GET 请求 'http://websafe-csrf-victim.dev/csrf/admin/admin_user/unsafe_create?admin%5Blogin%5D=admin002&admin%5Bpassword%5D=111111\' 来创建一个帐号为 'admin002', 密码为 '111111' 的管理员，虽然创建管理员之前会做用户认证，但是攻击者通过在站点 A(在此试验中可以通过 'websafe-csrf-attacker.dev' 访问站点 A, 在后面的描述中，站点 A 即代表 'websafe-csrf-attacker.dev') 上创建一个叫 hook 的页面来进行 CSRF 从而绕过站点 V 的验证来创建管理员。

hook 页面的 url: 'http://websafe-csrf-attacker.dev/csrf/attacker/hook'

hook 页面的内容：

<h2>攻击者在这个页面发起 CSRF 攻击</h2>

<p>下面这个 image 标签会创建一个叫 "admin002", 密码为 "111111" 的管理员</p>
<%= image_tag "http://websafe-csrf-victim.dev/csrf/admin/admin_user/unsafe_create?admin%5Blogin%5D=admin002&admin%5Bpassword%5D=111111" %>

站点 V 有一个初始的管理员，帐号是 'admin', 密码是 'verycomplex', 可以执行 bundle exec rake seed:admin_user 创建这个初始管理员。当 'admin' 成功登录站点 V 后，如果 'admin' 使用同一浏览器访问 'http://websafe-csrf-attacker.dev/csrf/attacker/hook' 后，站点 V 会在 'admin' 没有察觉的情况下增加一个新的管理员，

AdminUser.count #=> 2
AdminUser.last #=> #<AdminUser id: 7, login: "admin002", password: "111111", created_at: "2014-10-19 15:38:18", updated_at: "2014-10-19 15:38:18">

如果一个请求会改变资源的状态，比如下单请求，创建用户请求等，那么建议使用 POST 方法去完成这个请求，这样就不容易像上面的用例 1 一样被轻易的 CSRF, 所以我们在用例 2 中，将创建管理员的请求改为 POST 请求。

用例 2

在此用例中，攻击者把 hook 页面的内容变成了，

<h2>攻击者在这个页面发起 CSRF 攻击</h2>

<p>下面这个 image 标签会创建一个叫 "admin002", 密码为 "111111" 的管理员</p>
<%= image_tag "http://websafe-csrf-victim.dev/csrf/admin/admin_user/create?admin%5Blogin%5D=admin002&admin%5Bpassword%5D=111111" %>

我们注意到 unsafe_create 方法被改为了 create 方法。当然在真正的攻击中，攻击者不会告诉受害者这是一个 CSRF 页面，这里为了更清楚的演示试验过程，就加上了一些说明。我们看到攻击者使用一个新的链接 'http://websafe-csrf-victim.dev/csrf/admin/admin_user/create', 此链接的也是创建一个管理员，但是要求 POST 方法，其对应的路由和控制器内容如下，

路由内容，

namespace :csrf do

  scope :admin do
    post 'admin_user/create' => 'admin_user#create'
  end

end

控制器内容，

class Csrf::AdminUserController < ApplicationController

  skip_before_filter :verify_authenticity_token

  before_filter :auth_admin

  def create
    admin_user = AdminUser.create admin_user_params
    if admin_user
      render text: 'ok'
    else
      redirect_to :new
    end
  end

  private

  def admin_user_params
    params.required(:admin).permit(:login, :password)
  end

  def auth_admin
    if current_admin.nil?
      render text: '请登录'
    end
  end

  def current_admin
    @current_admin ||= AdminUser.where(id: session[:auid]).first
  end

  helper_method :current_admin

end

我们注意到控制器里的一段代码 skip_before_filter :verify_authenticity_token, 这段代码可以让我们的 create 方法不会去验证浏览器请求应用时发送过来的一个防止 CSRF 的 token, 这样我们的试验才可以进行下去。按照用例 1 的步骤，V 的管理员 'admin' 登录站点 V 后，使用同一浏览器访问攻击者设置的 'hook' 页面并不会增加一个新的管理员，这说明在应用设计中，对会改变资源状态的请求设置其请求方法为 POST 方法，能够抵挡一些比较初级简陋的 CSRF 攻击，如果攻击者动点心思在 'hook' 页面上增加一些恶意脚本，那么站点 V 的防线又被攻破了。

增加了恶意代码的 hook 页面的内容，

<h2>攻击者在这个页面发起 CSRF 攻击</h2>

<p>下面这个 image 标签会创建一个叫 "admin002", 密码为 "111111" 的管理员</p>
<%= image_tag "http://websafe-csrf-victim.dev/csrf/admin/admin_user/create?admin%5Blogin%5D=admin002&admin%5Bpassword%5D=111111" %>

<img src="/images/harmless.jpg" width="400" height="400" onmouseover="
 var f = document.createElement('form');
  f.style.display = 'none';
  this.parentNode.appendChild(f);
  f.method = 'POST';
  f.action = 'http://websafe-csrf-victim.dev/csrf/admin/admin_user/create?admin%5Blogin%5D=admin002&admin%5Bpassword%5D=111111';
  f.submit();
  return false;
     " />

我们注意到攻击者在页面上增加了一张本身无害的图片，但是他给这张图片增加了一个 'onmouseover' 事件，通过此事件，当受害者把鼠标移动到图片上时，脚本会创建一个 form 表单然后在受害者毫无察觉的情况下 POST 请求 'http://websafe-csrf-victim.dev/csrf/admin/admin_user/create' 地址，最后创建一个管理员。

hook 页面在浏览器上的显示内容：

用例 3

我们注意到在用例 2 中，控制器 'Csrf::AdminUserController' 里有一段代码：skip_before_filter :verify_authenticity_token, 现在我们把这段代码注释掉，然后重复用例 2 的步骤，这时候我们发现站点 V 抛出一个 ActionController::InvalidAuthenticityToken 的异常，这个异常是什么意思呢？我们首先查看下 V 的布局文件 application.html.erb, 其内容为：

<!DOCTYPE html>
<html>
<head>
  <title>Websafe</title>
  <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true %>
  <%= csrf_meta_tags %>
</head>
<body>

<%= yield %>

</body>
</html>

我们注意到 csrf_meta_tags 这段代码，它会帮我们在页面上嵌入一个存储 csrf-token 的 meta 标签，比如：'', 如果我们使用 form_tag, form_for 之类的表单辅助方法，rails 会自动帮我们生成一个包含 csrf-token 的隐藏 input 标签比如，

<div style="display:none">
  <input name="authenticity_token" type="hidden" value="OI3TMyEUCXA00tKNqjovRVf+6iHX49jdlne4S76H1qU=">
</div>

上面的 csrf-token meta 标签用于 jquery-ujs, 这样做 ajax post 请求时，jquery-ujs 会自动在请求头里加入 csrf-token meta 标签的内容，比如，

"authenticity_token"=>"OI3TMyEUCXA00tKNqjovRVf+6iHX49jdlne4S76H1qU="

而 form 表单里的 authenticity_token input 标签会在表单提交时将 authenticity_token 的值发送到服务器以供验证，这样只要是站内的请求就不用担心不能通过 csrf-token 认证了。

这个 token 是随机生成的，并且此 token 生成后会被保存到用户的会话中，即 session[:csrf_token], 而攻击者几乎是没有可能通过访问同一个页面来获得这个 token 的，因为 rails 会根据攻击者的会话生成一个不同的 token, 所以我们可以认为攻击者不知道这个 token, 在这种情况下，攻击者即使仿照了一个请求，也没有办法通过 rails 的 csrf-token 认证了，这样就预防了 CSRF 攻击了。

我们总结下在 rails 中怎么预防 CSRF 攻击，

不使用 GET 方法去请求一些有副作用的操作，比如创建资源，删除资源，更新修改资源等；
rails 默认会对使用 POST, PUT, DELETE 方法的请求启用 csrf-token 认证，所以我们在遵守第 1 条规矩的时候，使用 rails 的此默认设置就足够抵御大量的 CSRF 攻击了;

Session Fixation

Session Fixation 的攻击过程大致如下，

假设攻击者对站点 A 进行攻击

攻击者通过加载站点 A 的登录页面创建了一个合法的 session id, 然后从 A 的响应的 cookie 里取出此 session id 用于后面的操作;
攻击者通过一定的方法保持这个 session id 不过期，比如不断地访问站点 A;
同时攻击者可能通过某种方式让受害者的浏览器去使用这个 session id, 比如攻击这在站点 A 的某个页面注入了恶意代码， <script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script> 很显然这里用到了 XSS 攻击，当受害者访问到这个页面时，她浏览器的 session id 会被强制地使用被攻击者掌握的 session id 了；
受害者登录站点 A, 这时候攻击者和受害者就共享同一个 session id 了，这就意味着攻击者可以使用和受害者一样的身份使用站点 A 了，并且受害者对攻击没有丝毫察觉;

在 rails 中预防 Session Fixation 攻击要注意以下几点，

1.做好预防 XSS 攻击的工作，因为 Session Fixation 攻击的第三步就用到了 XSS, 而怎么预防 XSS 攻击我们在前面已经说了很多了;
2.使用 reset_session 方法， reset_session 方法会创建一个新的 session，这样攻击者持有的那个 session id 就失效了，所以每次用户登录成功后，我们先执行 reset_session, 然后再填充新的用户 session, 如下所示：

class Csrf::SessionController < ApplicationController

  def create
    @admin = authenticate_admin
    if @admin
      reset_session
      session[:auid] = @admin.id
      render text: '登录成功'
    else
      redirect_to :new
    end
  end

  private

  def authenticate_admin
    admin = AdminUser.where(login: params[:login]).first
    admin and admin.password == params[:password] ? admin : nil
  end

end

3.根据用户浏览器器的信息来判断是否有 Session Fixation 攻击，比如用户访问的 ip 发生了变化;

根据我的理解做好第 1，第 2 点就能很好的预防 Session Fixation 攻击了，但是第 3 点也是非常有意义的，比如，如果频繁的发现用户通过不同的 ip 或者浏览器登录，这预示着可能有 Session Fixation 攻击了。

Brute Force Attack

这是一种使用自动程序暴力破解的攻击手段，假设某个站点 A 有一个登录页面，当用户填写了错误的登录名后，页面上会显示 '用户名不存在的'，那么攻击者就很可能使用这个登录页面获得一批有效的用户名，然后配合密码字典等破解用户的帐号。我们预防 Brute Force 攻击可以从两个方面着手，

阻止自动程序的暴力请求，比如我们可以在登录页面或者其他需要识别自动程序的页面上增加验证码;
模糊出错信息，比如如果用户登录失败，无论是因为用户名错误还是密码错误，我们都可以显示为'用户名或者密码错误';

参考

试验用到的代码

websafe

XSS

HTTPOnly

https://www.owasp.org/index.php/HTTPOnly

Content Security Policy

大规模 I18n 实践

kayakjiang — Tue, 05 Jan 2016 16:15:48 +0800

这篇文章主要涉及到以下一些内容：

有时候我们用点心，会发现客户的建议是很明智的。
将用户的输入标准化。
使用 excel 文件作为用户操作翻译对象的 UI。
使用 redis 作为翻译数据的存储后端。
特例：处理邮件的翻译。

这篇文章的标题看起来有点唬人，这个大规模并不是说为了做这个 I18n 动用了很多机器，也不是说处理了大规模的并发请求，而是指 I18n 涉及到的国家和地区很多，翻译的内容也很多，这两多已经多到不能用 Rails 默认的方法来处理 I18n 了，既然不能使用 Rails 默认的方法来处理了，那么我们就需要自己动脑筋设计新的方法和程序来处理这个问题，在这篇文章中将介绍我们是如何在实际开发中处理这个大规模的 I18n 问题。

和我以往的文章一样这篇帖子提供了一个一步步构造出的可以运行的 demo,

本文 demo 代码在 https://github.com/baya/my-i18n-demo

问题概述与挑战

我们的项目是一个跨国电子商务网站，下面的图表示的是我们支持的国家和语言，

Rails 项目中默认以 yml 文件存储翻译内容，比如说 config/locales/en.yml,

# Files in the config/locales directory are used for internationalization
# and are automatically loaded by Rails. If you want to use locales other
# than English, add the necessary files in this directory.
#
# To use the locales, use `I18n.t`:
#
#     I18n.t 'hello'
#
# In views, this is aliased to just `t`:
#
#     <%= t('hello') %>
#
# To use a different locale, set it with `I18n.locale`:
#
#     I18n.locale = :es
#
# This would use the information in config/locales/es.yml.
#
# To learn more, please read the Rails Internationalization guide
# available at http://guides.rubyonrails.org/i18n.html.

en:
  hello: "Hello world"

这种存储方式有五大不足：

语言很多时需要添加很多翻译文件。
翻译内容很多时，文件会很大，存储效率不高，访问速度低下。
相同的语言在不同的国家其实是有差别的，比如英式英语和美式英语其实是有很多差别的，而这种存储方式不太好处理这种情况。
不能线上更新翻译内容，如果需要增加或者修改翻译需要更新 yml 文件，然后重新部署应用。
yml 文件对翻译人员不友好，最终将翻译集成到项目的大部分工作都落在了我们开发人员身上。

针对上述不足，我们对症下药，实施下面的解决方法：

将翻译的存储由 yml 文件改为 redis。
使用 lang-country 取代 lang 作为 locale, 比如 en-US, en-UK 等。
使用 excel 文件作为用户提交翻译的 UI, 我们在后台写程序解析 excel 文件，然后自动将翻译内容导入到 redis 中。

在开始实践之前，我们首先建立自己的 demo 项目 my-i18n-demo:

$ rails new my-i18n-demo

1. 使用 redis 作为翻译的存储后端

1.1 建立 redis.yml 文件

# config/redis.yml

i18n:
  host: 127.0.0.1
  port: 6379
  db: 1
  driver: hiredis
  thread_safe: true
  timeout: 200

1.2 建立 locales.yml 文件

为了简单起见，我们在 demo 中只演示简体中文 (zh-s), 繁体中文 (zh-t), 西班牙语 (es), 法语 (fr), 日语 (jp), 意大利语 (it), 俄语 (ru), 德语 (de), 英语 (en) 等几种语言。

# config/locales.yml

locales:
  zh-s:
    - CN
    - CA
    - US
  zh-t:
    - HK
    - TW
    - CA
    - US
  es:
    - ES
    - MX
    - US
    - CO
    - CR
    - DO
    - EC
    - PE
  de:
    - DE
  fr:
    - FR
    - CA
  it:
    - IT
  jp:
    - JP
  ru:
    - RU
  en:
    - US
    - GB
    - CA

locales.yml 文件的结构是：语言下面是一组使用该语言的国家和地区。

1.3 配置 redis 为翻译的存储后端

首先我们需要在 Gemfile 里引入 3 个 gem:

# Gemfile

+ gem "redis"
+ gem "hiredis"
+ gem 'cached_key_value_store'

gem hiredis 是对用 c 写的 hiredis 做的一个 ruby 封装，c 写的 hiredis 是 redis 的一个 c 客户端库，gem hiredis 最主要的作用就是提高对大批量的 redis 回复的解析速度。

cached_key_value_store 这个 gem 可以缓存一些比较慢的翻译请求，提高系统的响应速度。

最后不要忘记 bundle install。

然后创建 redis.rb 文件，

# config/initializers/redis.rb

require 'redis/connection/hiredis'

I18N_LOCALES = YAML.load_file(Rails.root.join('config', 'locales.yml'))['locales']

module I18n
  module Backend
    class KeyValue
     # 设定了合法的 locales
      def available_locales
        a = []
        I18N_LOCALES.each do |lang, countries|
          countries.each do |c|
            a << "#{lang}-#{c}"
          end
        end
        a
      end
    end
  end
end

$i18n_redis = Redis.new(YAML.load_file("#{Rails.root}/config/redis.yml")['i18n'])
I18n.backend = I18n::Backend::CachedKeyValueStore.new($i18n_redis)

这样配置 redis 的工作就全部完成了，接下来我们调试下以 redis 为存储后端的 I18n 是否正常工作。

1.4 调试 I18n 是否正常工作

首先我们从网上找一份常用的国际化数据，比如 https://github.com/svenfuchs/rails-i18n, 我们使用 zh-CN.yml 作为调试数据。我们把 zh-CN.yml 改名为 zh-s-CN.yml, 并将 zh-s-CN.yml 里的 zh-CN 改为 zh-s-CN,

# config/locales/zh-s-CN.yml
+ zh-s-CN

调试的步骤如下：

将 zh-s-CN.yml 导入到 redis。
进入 rails console, 然后查看 zh-s-CN 的翻译是否正确。

1.4.1 将 zh-s-CN.yml 导入到 redis

我们先将 zh-CN.yml 文件下载到 config/locales

$ wget https://raw.githubusercontent.com/svenfuchs/rails-i18n/master/rails/locale/zh-CN.yml

接着我们启动 redis，启动 redis 之前，我们需要用到一个 redis 的配置文件 redis.conf, 可以从 https://raw.githubusercontent.com/baya/my-conf/master/redis.conf 下载，我们将 redis.conf 放到 /usr/local/etc/ 目录下，根据 redis.conf 里面 dir /usr/local/var/db/redis/ 的配置，如果没有 /usr/local/var/db/redis/ 这个目录，我们需要创建 /usr/local/var/db/redis/ 这个目录，$ mkdir -p /usr/local/var/db/redis/, 现在可以启动 redis 了，

$ redis-server /usr/local/etc/redis.conf

我们写一个 rake task 用于将 zh-s-CN.yml 导入到 redis，

# lib/tasks/load_translations.rake

namespace :data do
  task :load_translations, [:locale] => [:environment] do |t, args|
    locale = args['locale']
    file = [locale, 'yml'].join('.')
    translations = YAML.load_file(Rails.root.join('config/locales', file))[locale]

    I18n.backend.store_translations(locale, translations, :escape => false)
  end
end

执行 data:load_translations task 导入翻译数据，

$ bundle exe rake data:load_translations[zh-s-CN]

1.4.2 进入 rails console 调试

> I18n.locale = 'zh-s-CN'
> I18n.t('date.abbr_day_names')
=> ["周日", "周一", "周二", "周三", "周四", "周五", "周六"] 

> I18n.t('date.day_names')
=> ["星期日", "星期一", "星期二", "星期三", "星期四", "星期五", "星期六"]

> I18n.t('datetime.distance_in_words.about_x_hours')
=> {:one=>"大约一小时", :other=>"大约 %{count} 小时"} 

> I18n.t('datetime.distance_in_words.about_x_hours.other', count: 1)
=> "大约 1 小时"

> I18n.t('errors.format')
=> "%{attribute}%{message}"

> I18n.t('errors.messages.greater_than', count: 0)
=> "必须大于 0"

Cool, 工作正常。

2. 用户线上提交翻译

我们开发过一个功能很完备的 web 界面让用户去提交和管理翻译数据，但是用户经常抱怨不会使用这个界面，后来我们发现用户是使用 excel 文件来编辑和保存翻译好的数据，于是我们想何不直接提供一个上传文件的界面，让用户直接上传 excel 文件，然后我们在后台将文件内容导入到 redis 里不就行了？后来我们开发了这样一个上传 excel 文件到界面，果然很好用，用户不再抱怨了。现在我们在 my-i18n-demo 中实现这个功能。

2.1 标准化用户输入

在和用户讨论后，我们决定每条翻译记录的第 1 列为 locale, 第 2 列为翻译 key, 第 3 列为翻译 key 的英文内容，第 4 列为翻译内容。样本文件如下图所示，

2.2 写代码

设置路由：

# config/routes.rb

Rails.application.routes.draw do

+  namespace :admin do
+    resources :translation_files
+  end

end

生成控制器：

$ bundle exe rails g controller admin/translation_files

我们建立 TranslationFile 模型来处理上传的翻译文件，

# app/models/translation_file.rb

# encoding: utf-8
class TranslationFile

  attr_reader :errors

  Spreadsheet.client_encoding = 'UTF-8'

  def self.load_to_backend(file)
    file = new(file)
    file.to_backend
    file.errors
  end

  def initialize(file)
    @file   = file
    @errors = []    
  end

  def to_backend
    dict.each {|locale, value|
      I18n.backend.store_translations(locale, value, escape: false)
    }
  rescue Exception => e
    Rails.logger.info(e.message)
    Rails.logger.info(e.backtrace.join("\n"))
    @errors << [e.class, e.message]
  end


  private

  def book
    @book ||= Spreadsheet.open(@file)
  end

  def sheet
    @sheet ||= book.worksheet(0)
  end

  def dict
    if @dict.nil?
      @dict = {}
      sheet.each do |row|
        locale, key, _, value = row
        locale = locale.gsub(/\s/, '')
        key = key.gsub(/\s/, '')

        @dict[locale] ||= {}
        @dict[locale][key] = value
      end
    end

    @dict
  end

end

因为我们需要用到 spreadsheet 这个 gem 来处理 xls 文件，所以我们需要在 Gemfile 增加 spreadsheet,

# Gemfile
+ gem 'spreadsheet'

TranslationFilesController 的代码，

# app/controllers/admin/translation_files_controller.rb

class Admin::TranslationFilesController < ApplicationController

  def index
    @locales = I18n.backend.available_locales
    @key = 'hello_world'
  end

  def new
  end

  def create
    file = params[:file].tempfile
    errors = TranslationFile.load_to_backend(file)
    if errors.blank?
      redirect_to action: 'index'
    else
      flash[:error] = errors.map {|e| e.join(":")}.join(";")
      redirect_to action: 'new'
    end
  end

end

当我们成功提交 hello_world.xls 文件后，我们可以看到 Hello World 的各个语言的翻译，

特例：邮件的翻译

在邮件的翻译过程中，我们没有使用 I18n, 而是根据不同的 locale, 建立对应的邮件模版，比如 zh-s-CN 的欢迎邮件，我们就建立一个叫 _zh_s_cn_welcome_mail.html.erb 的邮件模版，这样做是因为邮件的翻译内容一般是大段的，并且这大段的内容又会因为不同的 locale 而产生不一些细微的差异，最重要的原因是邮件是发给客户的，如果邮件内容出现错误我们是没有办法把已经发送的邮件撤销重新发送，所以我们需要尽最大的努力确保邮件内容不会因为在线上修改翻译内容时而出现错误。

使用 Rails 构建 API 实践

kayakjiang — Sun, 31 May 2015 13:06:36 +0800

我是来鼓吹使用 Rails 写 API 的。

原文在此：https://labs.kollegorna.se/blog/2015/04/build-an-api-now/

原文有一个很大的缺陷就是读者无法按照它的步骤一步一步的去实现一个可以运行的 demo, 这对经验丰富的开发者可能不算是一个问题，但是对刚刚接触这方面知识的新手来说却是一个很大的遗憾，软件开发方面的知识重在实践，只有动手做了，才能对知识掌握地更加牢靠，才能更好地在工作中去使用这些知识，所以我对原文的内容做了一些补充修整，以期能够让读者边读边思考边实践。

原文的 demo 是一个类微博应用，为简单起见我们只使用 User 和 Micropost 模型，并且我们不使用 ActiveModel::Serializer, 而是使用 Jbuilder 作为 json 模版。

首先建立一个项目：build-an-api-rails-demo

$ rails new build-an-api-rails-demo

加入第一个 API resource

BaseController

生成控制器：

# 我们不需要生成资源文件
$ bundle exe rails g controller api/v1/base --no-assets

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController
  # disable the CSRF token
  protect_from_forgery with: :null_session

  # disable cookies (no set-cookies header in response)
  before_action :destroy_session

  # disable the CSRF token
  skip_before_action :verify_authenticity_token

  def destroy_session
    request.session_options[:skip] = true
  end
end

在 BaseController 里我们禁止了 CSRF token 和 cookies

配置路由：

config/routes.rb,

namespace :api do
  namespace :v1 do
    resources :users, only: [:index, :create, :show, :update, :destroy]
    # 原文有 microposts, 我们现在把它注释掉
    # resources :microposts, only: [:index, :create, :show, :update, :destroy]
  end
end

Api::V1::UsersController

生成控制器：

# 我们不需要生成资源文件
$ bundle exe rails g controller api/v1/users --no-assets

app/controllers/api/v1/users_controller.rb,

class Api::V1::UsersController < Api::V1::BaseController
  def show
    @user = User.find(params[:id])

    # 原文使用 Api::V1::UserSerializer
    # 我们现在使用 app/views/api/v1/users/show.json.jbuilder
    # render(json: Api::V1::UserSerializer.new(user).to_json)
  end
end

app/views/api/v1/users/show.json.jbuilder,

json.user do
  json.(@user, :id, :email, :name,  :activated, :admin, :created_at, :updated_at)
end

User 模型和 users 表

$ bundle exe rails g model User

app/models/user.rb,

class User < ActiveRecord::Base
end

db/migrate/20150502072954_create_users.rb,

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :email
      t.string :name
      t.datetime :activated
      t.boolean :admin, default: false
      t.timestamps null: false
    end
  end
end

数据迁移：

$ bundle exe rake db:migrate

种子数据：

db/seeds.rb,

users = User.create([
                     {
                       email: 'test-user-00@mail.com',
                       name: 'test-user-00',
                       activated: DateTime.now,
                       admin: false
                     },
                     {
                       email: 'test-user-01@mail.com',
                       name: 'test-user-01',
                       activated: DateTime.now,
                       admin: false
                     }
                    ])

创建种子数据：

$ bundle exe rake db:seed

现在我们可以测试一下 api 是否正常工作，我们可以先查看下相关 api 的路由，

$ bundle exe rake routes

输出：

      Prefix Verb   URI Pattern                      Controller#Action
api_v1_users GET    /api/v1/users(.:format)          api/v1/users#index
             POST   /api/v1/users(.:format)          api/v1/users#create
 api_v1_user GET    /api/v1/users/:id(.:format)      api/v1/users#show
             PATCH  /api/v1/users/:id(.:format)      api/v1/users#update
             PUT    /api/v1/users/:id(.:format)      api/v1/users#update
             DELETE /api/v1/users/:id(.:format)      api/v1/users#destroy

启动 rails 服务，

$ bundle exe rails s

使用 curl 请求 api,

$ curl -i http://localhost:3000/api/v1/users/1.json

{"user":{"id":1,"email":"test-user-00@mail.com","name":"test-user-00","activated":"2015-05-02T07:47:14.697Z","admin":false,"created_at":"2015-05-02T07:47:14.708Z","updated_at":"2015-05-02T07:47:14.708Z"}}

恭喜，我们的 api 工作正常！

增加认证 (Authentication)

认证的过程是这样的：用户把她的用户名和密码通过 HTTP POST 请求发送到我们的 API (在这里我们使用 sessions 端点来处理这个请求), 如果用户名和密码匹配，我们会把 token 发送给用户。这个 token 就是用来证明用户身份的凭证。然后在以后的每个请求中，我们都通过这个 token 来查找用户，如果没有找到用户则返回 401 错误。

给 User 模型增加 authentication_token 属性

$ bundle exe rails g migration add_authentication_token_to_users

db/migrate/20150502123451_add_authentication_token_to_users.rb

class AddAuthenticationTokenToUsers < ActiveRecord::Migration
  def change
    add_column :users, :authentication_token, :string
  end
end

$ bundle exe rake db:migrate

生成 authentication_token

app/models/user.rb,

class User < ActiveRecord::Base

 + before_create :generate_authentication_token

 + def generate_authentication_token
 +   loop do
 +     self.authentication_token = SecureRandom.base64(64)
 +     break if !User.find_by(authentication_token: authentication_token)
 +   end
 + end

 + def reset_auth_token!
 +   generate_authentication_token
 +   save
 + end

end

和原文相比，我给 User 模型增加了一个 reset_auth_token! 方法，我这样做的理由主要有以下几点：

我觉得需要有一个方法帮助用户重置 authentication token, 而不仅仅是在创建用户时生成 authenticeation token；
如果用户的 token 被泄漏了，我们可以通过 reset_auth_token! 方法方便地重置用户 token;

sessions endpoint

生成 sessions 控制器，

# 我们不需要生成资源文件
$ bundle exe rails g controller api/v1/sessions --no-assets

  create  app/controllers/api/v1/sessions_controller.rb
  invoke  erb
  create    app/views/api/v1/sessions
  invoke  test_unit
  create    test/controllers/api/v1/sessions_controller_test.rb
  invoke  helper
  create    app/helpers/api/v1/sessions_helper.rb
  invoke    test_unit

app/controllers/api/v1/sessions_controller.rb,

class Api::V1::SessionsController < Api::V1::BaseController

  def create
    @user = User.find_by(email: create_params[:email])
    if @user && @user.authenticate(create_params[:password])
      self.current_user = @user
      # 我们使用 jbuilder
      # render(
      #   json: Api::V1::SessionSerializer.new(user, root: false).to_json,
      #   status: 201
      # )
    else
      return api_error(status: 401)
    end
  end

  private

  def create_params
    params.require(:user).permit(:email, :password)
  end

end

现在我们还需要做一些原文没有提到的工作：

给 User 模型增加和 password 相关的属性;
给数据库中已存在的测试用户增加密码和 authentication token;
实现和 current_user 相关的方法;
实现 app/views/api/v1/sessions/create.json.jbuilder;
配置和 sessions 相关的路由;

给 User 模型增加和 password 相关的属性

在 Gemfile 里将 gem 'bcrypt' 这一行的注释取消

# Use ActiveModel has_secure_password
gem 'bcrypt', '~> 3.1.7'

app/models/user.rb,

class User < ActiveRecord::Base
  + has_secure_password
end

给 User 模型增加 password_digest 属性，

$ bundle exe rails g migration add_password_digest_to_users

db/migrate/20150502134614_add_password_digest_to_users.rb,

class AddPasswordDigestToUsers < ActiveRecord::Migration
  def change
    add_column :users, :password_digest, :string
  end
end

$ bundle install

$ bundle exe rake db:migrate

给数据库中已存在的测试用户增加密码和 authentication token

这个任务可以在 rails console 下完成，

首先启动 rails console,

$ bundle exe rails c

然后在 rails console 里执行，

User.all.each {|user|
  user.password = '123123'
  user.reset_auth_token!
}

实现和 current_user 相关的方法

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController

+ attr_accessor :current_user

end

实现 app/views/api/v1/sessions/create.json.jbuilder

app/views/api/v1/sessions/create.json.jbuilder,

json.session do
  json.(@user, :id, :name, :admin)
  json.token @user.authentication_token
end

配置和 sessions 相关的路由

Rails.application.routes.draw do

  namespace :api do
    namespace :v1 do
     + resources :sessions, only: [:create]
    end
  end

end

现在我们做一个测试看是否能够顺利地拿到用户的 token, 我们使用下面的用户作为测试用户：

{
  email: 'test-user-00@mail.com',
  name: 'test-user-00'
}

$ curl -i -X POST -d "user[email]=test-user-00@mail.com&user[password]=123123" http://localhost:3000/api/v1/sessions.json

{"session":{"id":1,"name":"test-user-00","admin":false,"token":"izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w=="}}

我们顺利地拿到了 token。

我们再做一个验证失败的测试。

我们使用一个错误的密码：fakepwd

curl -i -X POST -d "user[email]=test-user-00@mail.com&user[password]=fakepwd" http://localhost:3000/api/v1/sessions.json

糟糕系统出错了：

NoMethodError (undefined method `api_error' for #<Api::V1::SessionsController:0x007fead422c178>):
  app/controllers/api/v1/sessions_controller.rb:14:in `create'

原来我们没有实现 api_error 这个方法，那我们现在就实现 api_error 这个方法。

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController

 + def api_error(opts = {})
 +   render nothing: true, status: opts[:status]
 + end

end

继续测试：

curl -i -X POST -d "user[email]=test-user-00@mail.com&user[password]=fakepwd" http://localhost:3000/api/v1/sessions

HTTP/1.1 401 Unauthorized 
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache
X-Request-Id: a5349b47-d756-4830-84f8-0653577f936d
X-Runtime: 0.319768
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Sat, 02 May 2015 14:41:55 GMT
Content-Length: 0
Connection: Keep-Alive

此时服务器返回了 401 Unauthorized

Authenticate User

在前面的测试中，我们已经成功地拿到了用户的 token, 那么现在我们把 token 和 email 发给 API

看能否成功识别出用户。

首先在 Api::V1::BaseController 里实现 authenticate_user! 方法：

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController

+  def authenticate_user!
+    token, options = ActionController::HttpAuthentication::Token.token_and_options(request)

+    user_email = options.blank?? nil : options[:email]
+    user = user_email && User.find_by(email: user_email)

+    if user && ActiveSupport::SecurityUtils.secure_compare(user.authentication_token, token)
+      self.current_user = user
+    else
+      return unauthenticated!
+    end
+  end

end

ActionController::HttpAuthentication::Token 是 rails 自带的方法，可以参考 rails 文档了解其详情。

当我们通过 user_email 拿到 user 后，通过 ActiveSupport::SecurityUtils.secure_compare

对 user.authentication_token 和从请求头里取到的 token 进行比较，如果匹配则认证成功，否则返回

unauthenticated!。这里使用了 secure_compare 对字符串进行比较，是为了防止时序攻击 (timing attack)

我们构造一个测试用例，这个测试用例包括以下一些步骤：

用户登录成功，服务端返回其 email, token 等数据
用户请求 API 更新其 name, 用户发送的 token 合法，更新成功
用户请求 API 更新其 name, 用户发送的 token 非法，更新失败

为了让用户能够更新其 name, 我们需要实现 user update API, 并且加入 before_action :authenticate_user!, only: [:update]

app/controllers/api/v1/users_controller.rb,

class Api::V1::UsersController < Api::V1::BaseController

+ before_action :authenticate_user!, only: [:update]

+ def update
+   @user = User.find(params[:id])
+   @user.update_attributes(update_params)
+ end

+ private

+ def update_params
+   params.require(:user).permit(:name)
+ end

end

app/views/api/v1/users/update.json.jbuilder,

json.user do
  json.(@user, :id, :name)
end

现在我们进行测试，测试用户是：

{
  id: 1,
  email: 'test-user-00@mail.com',
  name: 'test-user-00',
  authentication_token: 'izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w=='
}

$ curl -i -X PUT -d "user[name]=gg-user" \
  --header "Authorization: Token token=izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w==, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/1

{"user":{"id":1,"name":"gg-user"}}

我们看到 user name 已经成功更新为 gg-user。

读者们请注意：你们自己测试时需要将 token 换为你们自己生成的 token。

我们使用一个非法的 token 去请求 API, 看看会发生什么状况。

curl -i -X PUT -d "user[name]=bb-user" \
  --header "Authorization: Token token=invalid token, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/1

服务器出现错误：

NoMethodError (undefined method `unauthenticated!' for #<Api::V1::UsersController:0x007fead6108d80>)

接下来我们实现 unauthenticated! 方法。

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController

+ def unauthenticated!
+   api_error(status: 401)
+ end

end

继续上面的测试：

curl -i -X PUT -d "user[name]=bb-user" \
  --header "Authorization: Token token=invalid token, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/1

HTTP/1.1 401 Unauthorized 
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache
X-Request-Id: 8cf07968-1fd0-4041-866a-ddea49af11d3
X-Runtime: 0.005578
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Sun, 03 May 2015 05:51:52 GMT
Content-Length: 0
Connection: Keep-Alive

服务器返回 401 Unauthorized, 并且 user name 没有被更新。

增加授权 (Authorization)

上面的测试有个问题，就是当前登录的用户可以把其他用户的 name 更新，这个应该是不被允许的，所以我们还需要增加一个权限认证的机制。在这里我们使用 Pundit 来实现权限认证。

安装 pundit

Gemfile,

+ gem 'pundit'

$ bundle install

app/controllers/api/v1/base_controller.rb,

class Api::V1::BaseController < ApplicationController
  + include Pundit
end

$ bundle exe rails g pundit:install

create  app/policies/application_policy.rb

将 policies 目录放到 rails 的自动加载路径中：

config/application.rb,

module BuildAnApiRailsDemo
  class Application < Rails::Application
+    config.autoload_paths << Rails.root.join('app/policies')
  end
end

创建和 user 相关的权限机制

app/policies/user_policy.rb,


class UserPolicy < ApplicationPolicy

  def show?
    return true
  end

  def create?
    return true
  end

  def update?
    return true if user.admin?
    return true if record.id == user.id
  end

  def destroy?
    return true if user.admin?
    return true if record.id == user.id
  end

  class Scope < ApplicationPolicy::Scope
    def resolve
      scope.all
    end
  end

end

使用 `UserPolicy`

app/controllers/api/v1/users_controller.rb,

class Api::V1::UsersController < Api::V1::BaseController

  def update
    @user = User.find(params[:id])
+   return api_error(status: 403) if !UserPolicy.new(current_user, @user).update?
    @user.update_attributes(update_params)
  end

end

测试：

$ curl -i -X PUT -d "user[name]=gg-user" \
  --header "Authorization: Token token=izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w==, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/2.json

HTTP/1.1 403 Forbidden 
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block

注意我们测试的 url 地址是 http://localhost:3000//api/v1/users/2, 也就是说我们在更新 id 为 2 的那个用户的 name。此时服务器返回的是 403 Forbidden。

pundit 提供了更简便的 authorize 方法为我们做权限认证的工作。


class Api::V1::UsersController < Api::V1::BaseController

  def update
    @user = User.find(params[:id])
    # return api_error(status: 403) if !UserPolicy.new(current_user, @user).update?
+   authorize @user, :update?
    @user.update_attributes(update_params)
  end

end

测试：


$ curl -i -X PUT -d "user[name]=gg-user" \
  --header "Authorization: Token token=izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w==, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/2.json

此时服务器报 Pundit::NotAuthorizedError 错误，

Pundit::NotAuthorizedError (not allowed to update?

我们可以使用 rescue_from 捕捉 Pundit::NotAuthorizedError 这类异常。

class Api::V1::BaseController < ApplicationController

  include Pundit

+  rescue_from Pundit::NotAuthorizedError, with: :deny_access

+  def deny_access
+    api_error(status: 403)
+  end

end

测试：

$ curl -i -X PUT -d "user[name]=gg-user" \
  --header "Authorization: Token token=izrFiion7xEe2ccTj0v0mOcuNoT3FvpPqI31WLSCEBLvuz4xSr0d9+VI2+xVvAJjECIoju5MaoytEcg6Md773w==, \
  email=test-user-00@mail.com" \
  http://localhost:3000//api/v1/users/2

HTTP/1.1 403 Forbidden 
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: text/plain; charset=utf-8

这次服务器直接返回 403 Forbidden

分页

我们现在要实现一个展示用户发的微博的 API, 如果用户的微博数量很多，那么我们应该用上分页。

建立 Micropost 模型

$ bundle exe rails g model Micropost

db/migrate/20150503131743_create_microposts.rb,

class CreateMicroposts < ActiveRecord::Migration
  def change
    create_table :microposts do |t|
      t.string :title
      t.text :content
      t.integer :user_id
      t.timestamps null: false
    end
  end
end

执行：

$ bundle exe rake db:migrate

为 id 为 1 的用户创建 100 条微博纪录：

lib/tasks/data.rake,

namespace :data do
  task :create_microposts => [:environment] do
    user = User.find(1)
    100.times do |i|
      Micropost.create(user_id: user.id, title: "title-#{i}", content: "content-#{i}")
    end
  end
end

执行：

$ bundle exe rake data:create_microposts

Api::V1::MicropostsController

执行：

$ bundle exe rails g controller api/v1/microposts --no-assets

配置路由：

config/routes.rb,

Rails.application.routes.draw do

  namespace :api do
    namespace :v1 do
 +    scope path: '/user/:user_id' do
 +      resources :microposts, only: [:index]
 +    end
    end
  end

end

此时和 microposts 相关的路由如下：

api_v1_microposts GET    /api/v1/user/:user_id/microposts(.:format) api/v1/microposts#index

我们使用 kaminari 这个 gem 进行分页。

安装 kaminari,

Gemfile

+ gem 'kaminari'

执行：

$ bundle install

app/models/user.rb

class User < ActiveRecord::Base

 + has_many :microposts

end

app/controllers/api/v1/microposts_controller.rb

class Api::V1::MicropostsController < Api::V1::BaseController

+  def index
+    user = User.find(params[:user_id])
+    @microposts = paginate(user.microposts)
+  end

end

app/controllers/api/v1/base_controller.rb

class Api::V1::BaseController < ApplicationController

  def paginate(resource)
    resource = resource.page(params[:page] || 1)
    if params[:per_page]
      resource = resource.per(params[:per_page])
    end

    return resource
  end

end

app/helpers/application_helper.rb

module ApplicationHelper

+  def paginate_meta_attributes(json, object)
+    json.(object,
+          :current_page,
+          :next_page,
+          :prev_page,
+          :total_pages,
+          :total_count)
+  end

end

app/views/api/v1/microposts/index.json.jbuilder,

json.paginate_meta do
  paginate_meta_attributes(json, @microposts)
end
json.microposts do
  json.array! @microposts do |micropost|
    json.(micropost, :id, :title, :content)
  end
end

测试：

$ curl -i -X GET http://localhost:3000/api/v1/user/1/microposts.json?per_page=3

{
    "paginate_meta": {
    "current_page":1,
    "next_page":2,
    "prev_page":null,
    "total_pages":34,
    "total_count":100
    },
    "microposts":[
    {"id":1,"title":"title-0","content":"content-0"},
    {"id":2,"title":"title-1","content":"content-1"},
    {"id":3,"title":"title-2","content":"content-2"}
    ]
}

API 调用频率限制 (Rate Limit)

我们使用 redis-throttle 来实现这个功能。

Gemfile,

gem 'redis-throttle', git: 'git://github.com/andreareginato/redis-throttle.git'

执行，

$ bundle install

集成到 Rails 中：

config/application.rb,

# At the top of config/application.rb
+ require 'rack/redis_throttle'

class Application < Rails::Application
  # Limit the daily number of requests to 3
  # 为了测试我们把 limit 设置为 3
+ config.middleware.use Rack::RedisThrottle::Daily, max: 3
end

我们开始测试，请求 http://localhost:3000/api/v1/users/1 4 次看会出现什么结果。

前面 3 次请求一切正常，

curl -i http://localhost:3000/api/v1/users/1

HTTP/1.1 200 OK 
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: application/json; charset=utf-8
X-Ratelimit-Limit: 3
X-Ratelimit-Remaining: 0
Etag: W/"eb58510a43ebc583cf61de35b6d20093"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: bbe7437b-ba6e-4cfd-a4ef-49eec4c611fd
X-Runtime: 0.014384
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Thu, 07 May 2015 13:03:31 GMT
Content-Length: 199
Connection: Keep-Alive

{"user":{"id":1,"email":"test-user-00@mail.com","name":"gg-user","activated":"2015-05-02T07:47:14.697Z","admin":false,"created_at":"2015-05-02T07:47:14.708Z","updated_at":"2015-05-03T05:40:24.931Z"}}

我们注意服务器返回的两个响应头：X-Ratelimit-Limit 和 X-Ratelimit-Remaining,

X-Ratelimit-Limit 的值一直为 3，表示请求的限制值，

而 X-Ratelimit-Remaining 每请求一次，其值会减 1，直到为 0。

第 4 次请求出现 403 Forbidden, 这说明 redis-throttle 起到了其应有的作用。

curl -i http://localhost:3000/api/v1/users/1 

HTTP/1.1 403 Forbidden 
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache
X-Request-Id: fd646f00-a6a8-411d-b5e4-24856c63b078
X-Runtime: 0.002375
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Thu, 07 May 2015 13:03:33 GMT
Content-Length: 35
Connection: Keep-Alive

403 Forbidden (Rate Limit Exceeded)

redis-throttle 的 redis 连接默认是 redis://localhost:6379/0, 你也可以通过设置环境变量

ENV['REDIS_RATE_LIMIT_URL'] 来改变 redis-throttle 的 redis 连接。

CORS

CORS 是 Cross Origin Resource Sharing 的缩写。简单地说 CORS 可以允许其他域名的网页通过 AJAX 请求你的 API。

我们可以使用 rack-cors gem 来帮助我们的 API 实现 CORS。

Gemfile,

+ gem 'rack-cors'

config/application.rb,

module BuildAnApiRailsDemo
  class Application < Rails::Application

+    config.middleware.insert_before 0, "Rack::Cors" do
+      allow do
+        origins '*'
+        resource '*', :headers => :any, :methods => [:get, :post, :put, :patch, :delete, :options, :head]
+      end
+    end

  end
end

Version 2 API

随着我们的业务发展，我们的 API 需要做较大的改变，同时我们需要保持 Version 1 API, 所以我们开始开发 Version 2 API。

routes

config/routes.rb,

Rails.application.routes.draw do

  namespace :api do
    namespace :v1 do
      resources :users, only: [:index, :create, :show, :update, :destroy]
      # resources :microposts, only: [:index, :create, :show, :update, :destroy]
      resources :sessions, only: [:create]
      scope path: '/user/:user_id' do
        resources :microposts, only: [:index]
      end
    end

+    namespace :v2 do
+      resources :users, only: [:index, :create, :show, :update, :destroy]
+      resources :sessions, only: [:create]
+      scope path: '/user/:user_id' do
+        resources :microposts, only: [:index]
+      end
+    end

  end

end

controller

生成 API::V2::UsersController, 其他控制器的生成类似

$ bundle exe rails g controller api/v2/users --no-assets

app/controllers/api/v2/users_controller.rb,


class Api::V2::UsersController < Api::V1::UsersController

  def show
    @user = User.find(params[:id])
  end

end

app/vies/api/v2/users/show.json.jbuilder,

json.user do
  json.(@user, :id, :email, :name,  :activated, :admin, :created_at, :updated_at)
end

测试：

$ curl -i http://localhost:3000/api/v2/users/1.json

{"user":{"id":1,"email":"test-user-00@mail.com","name":"gg-user","activated":"2015-05-02T07:47:14.697Z","admin":false,"created_at":"2015-05-02T07:47:14.708Z","updated_at":"2015-05-03T05:40:24.931Z"}}%

文档

原文提到了下面的几种文档工具：

和原文一样，我也喜欢使用 slate 作为文档工具。

将 slate 集成到项目中

创建 docs 目录，

$ mkdir app/docs

集成 slate,

$ cd app/docs

$ git clone git@github.com:tripit/slate.git

$ rm -rf slate/.git

$ cd slate

$ bundle install

配置构建目录，app/docs/slate/config.rb


+ set :build_dir, '../../../public/docs/'

现在我们开始编写获取用户信息这个 API 的文档。

app/docs/slate/source/index.md,

---
title: API Reference

language_tabs:
  - ruby

toc_footers:
  - <a href='http://github.com/tripit/slate'>Documentation Powered by Slate</a>

includes:
  - errors

search: true
---

# 介绍

API 文档

# 获取用户信息

## V1

## HTTP 请求

`GET http://my-site/api/v1/users/<id>`

## 请求参数

参数名 | 是否必需 | 描述
-----| --------| -------
id   |  是      | 用户 id|

## 响应

\```json
{
  "user":
  {
    "id":1,
    "email":"test-user-00@mail.com",
    "name":"test-user-00",
    "activated":"2015-05-02T07:47:14.697Z",
    "admin":false,
    "created_at":"2015-05-02T07:47:14.708Z",
    "updated_at":"2015-05-02T07:47:14.708Z"
   }
}
\```

注意：index.md 范例里的 json 代码语法高亮部分有转义字符，直接复制可能没法看到语法高亮效果，在实际使用时需要将 ``` 前面的 '\' 符号去掉。

build 脚本

docs_build.sh,

#!/bin/bash

cd app/docs/slate

bundle exec middleman build --clean

build docs,

$ chmod +x docs_build.sh

$ ./docs_build.sh

可以通过 http://localhost:3000/docs/index.html 访问文档

给 API 文档添加访问控制

配置路由：

routes.rb,

+ get '/docs/index', to: 'docs#index'

建立相关控制器：

$ bundle exe rails g controller docs

app/controllers/docs_controller.rb,

class DocsController < ApplicationController

  USER_NAME, PASSWORD = 'doc_reader', '123123'

  before_filter :basic_authenticate

  layout false

  def index
  end

  private

  def basic_authenticate
    authenticate_or_request_with_http_basic do |user_name, password|
      user_name == USER_NAME && password == PASSWORD
    end
  end

end

同时我们需要把 public/docs/index.html 文件转移到 app/views/docs/ 目录下面，我们

可以更改 docs_build.sh 脚本，注意 docs_build.sh 应该放在项目的根目录下，比如：/path/to/build-an-api-rails-demo/docs_build.sh,

#!/bin/bash

app_dir=`pwd`
cd $app_dir/app/docs/slate

bundle exec middleman build --clean

cd $app_dir

mv $app_dir/public/docs/index.html $app_dir/app/views/docs

重新 build 文档，

$ ./docs_build.sh

浏览器访问 http://localhost:3000/docs/index.html,

提示需要输入用户名和密码，我们输入正确的用户名 (doc_reader) 和密码 (123123) 后就可以正常访问文档了，

项目代码

build-an-api-rails-demo

感谢 @lazybios 同学提的 5 点建议，让本文变的更好。

感谢 @night_7th 提的注明 skip_before_filter :verify_authenticity_token 的建议。

[北京] Magus Soft 公司招聘 Ruby 工程师 3 名

kayakjiang — Fri, 14 Nov 2014 18:00:44 +0800

香港新空气控股（Magus Soft Holding）致力于投资、发展基于无线互联网络的新技术与新应用。2001 年投资成立北京新空气软件技术有限公司。

空气的使命是给用户提供移动互联应用综合解决方案，在手机游戏、电信运营商移动增值服务等方面始终保持着行业技术的领先水平，与三大运营商建立了战略合作关系，并在 2012 年成为英特尔的合作伙伴，2013 年加入微软 BizSpark 企业扶植计划，2014 年成为亚马逊 AWS 合作伙伴。

新空气努力为公众提供便捷的移动生活体验，将移动互联的前沿技术应用于社会生活的方方面面，推出的国内首个银行类客户端产品---“招商银行掌上生活”，连续被评为苹果 APP 最受用户欢迎的财经类应用。

目前新空气专注于各类行业应用的设计、开发、运营、维护及推广，服务涉及手机银行、手机话费充值、手机彩票、手机影票等等。

更多信息可以通过 http://www.magus-soft.com/ 了解。

我们可以为您提供：行业领先的视角，快速成长的机会，稳定可观的福利待遇。诚邀您的加入！

加入 Magus Soft 的 N 条理由：

最先进的无线互联网技术产品开发团队；
开放式办公－见解比职务重要；
员工第一；
Innovating Like MAD!
成为无线互联网开发、发行的国际领先企业；
提供极具竞争力的薪资福利待遇和发展前景；
组织不定期的员工活动，营造愉快的工作氛围；

诚邀 Ruby 开发者加入我们，目前采用 Ruby 所开发的增值业务稳定为千万级用户提供不间断服务，在用户数不断攀升的情况下，需要对系统做结构性的重构，需要熟悉掌握 Ruby 语言以及 Rails 开发框架。

只要您：

熟悉掌握 Ruby 语言，了解并能使用各个版本的 Rails
能在 Linux 下完成工作
对数据库有足够对认识
了解 HTTP 协议
有良好的代码书写和编程习惯、非常强的学习能力，有很强的分析和解决问题能力
在 github.com 有托管项目以及参与开源项目者更佳

就有机会：

为各大银行千万级用户提供服务
学习接触到最前沿到云计算平台 (AWS EC2,SQS,SNS,SWF,S3,RDS,DynamoDB,EMR 等等...)
有机会参与项目的设计和决策，拓宽视野
不仅局限于 Ruby，还能和其他技术团队混合开发

公司补充信息

公司目前的客户群主要有招商银行，建设银行，浦发银行，万达影院，海底捞等。

公司地址：北京市朝阳区朝阳北路 52 号院 4 号楼底商 3 号二层，大概方位是东五环离传媒大学很近。

薪资待遇

工资：8-18K
按国家规定五险一金

联系方式

hr-bj@funguide.com.cn

Ruby 工程师的简历会第一时间由 HR 转发给我们的技术负责人。

一步一步 DSL

kayakjiang — Mon, 06 Jan 2014 13:49:29 +0800

原文地址： http://baya.github.io/2013/12/06/%E4%B8%80%E6%AD%A5%E4%B8%80%E6%AD%A5dsl/

原文比较长哈，给个提纲，

大概是 12 年的 10 月份，想为公司的彩票，话费充值等业务定义一套DSL(Domain-specific language)，这套 DSL 主要用于添加渠道，添加产品，配置订单重试等，于是花了些时间学习了下 Ruby 的 DSL 技术，在学习和实践的过程中，我总结了下 Ruby 中常见的 DSL 风格及其常用技术实现，并且对怎样实践 DSL 形成了一些自己的感受。

第一部分，Ruby 中常见的 DSL 风格及其技术实现

我归纳了四种风格，很可能有遗漏或者描述的不够准确，欢迎大家在后面补充指正。

嵌套风格
链式风格
类宏风格
补丁风格

对于每种风格的 DSL，我给出了一些常见的技术实现，这些技术都能在我们一些常用的 gem 中找到相应的代码实现，比如 嵌套风格 的 DSL 可以通过yield, instance_eval, 转储&block, method_missing等实现，在 rails_admin, rack, rspec, jbuilder 等 gem 中能找到相关的代码作为例证和学习资料。

第二部分，Ruby 的 DSL 实践

在干完了一堆又一堆的脏活，累活后，我感觉世界清静了许多，人也清醒了许多，我只是一个程序员，摆在我面前的现实就是我要尽力在规定的时间内干完活，完成任务，而不是让上级怀疑我在偷懒，所以与其漫无目的去开发一种类似于 rails, activerecord 这种近乎业界标准的 DSL，还不如直面眼前的问题，一步一个脚印，快速而不失优雅的去解决眼前的问题。相对于 rails, activerecord 这种 Big DSL，我提出与之对应的一个概念 Small DSL，针对 Small DSL，我给 domain 做了一个定义，

是一个 class
可以接收外部数据

以上面的定义为基础，我写了一个 gem dun，这个 gem 里面只包含一个 class Dun::Land, 我们可以使用Dun::Land对 domain 进行封装，详细的用法可以看看https://github.com/baya/dun/blob/master/README.md

为什么会写这样一个 gem？主要基于下面四点的思考，

不要设计精巧的类 精巧的东西往往很脆弱。
真的要很直接 定义一个类，就表明你知道你想干的事情是什么，你想干的事情在这个类中就能解决了，而不是山路十八弯，还要牵扯到许多其他地方的代码。
拒绝过度的设计模式 与眼花缭乱的设计模式告别，回归我们最初的 程序 = 数据结构＋算法，确定一个类，也就确定了一个算法，实现了算法也就解决了问题。
写大量的并且可能枯燥的测试 写的每一个类都要测试，什么样的类好测试呢？小的， 单一职责的， 解耦合的， 带输入输出的 类好测试，为了更好的测试，你会发现你需要写许许多多的类，而不是把方法都塞到 model, controller 里面去了。

欢迎大家贴出自己写的感觉比较好的 DSL

写了一个小工具 Gstar,帮助你搜索在 github 上 star 过的项目

kayakjiang — Tue, 08 Oct 2013 22:52:47 +0800

一不小心在 github 上 star 过的项目将近 800 个了，我发现从这 800 个项目里找出我需要的项目不是一件容易的事情了，比如说印象里我有 star 过几个关于中文分词的 project，当我用 github 自带的搜星功能去搜索'中文分词'时，却发现什么也找不到，

那就动手自己写一个搜星工具吧。通过 Gstar 搜索'中文分词',

安装

一。git clone https://github.com/baya/Gstar.git

二。cd Gstar/ground

三。bundle install

四。rake db:migrate

五。cp config/github.example.yml config/github.yml

在 config/github.yml 里有三个配置，其中 login 为必填项，access_token 和 password 选一个填写即可， login 和 password 分别是你用来登录 github 的用户名和密码，access_token 可以通过下面的步骤得到，

点击 Account Settings，进入帐号设置页面
选择左侧栏的 Applications 导航，可以看到 Personal Access Tokens 这个设置，点击右上角的 Create new token 生成新的 access_token 即可。

六。rake maintain:pull_stars_from_github # 将你 star 过的项目从 github 拉到本地数据库

七。whenever --update # 启动定时任务，每分钟检查一次你是否有新的 star 项目

八。rackup -p 9292

九。使用浏览器访问 http://localhost:9292

注意操作三到八都是在 Gstar/ground 目录下进行的。

功能特点

1. 准确快速的搜索

github 自带的搜星功能不是特别好用，比如说我想找出我收藏的 (github 的标星功能对我来说就是收藏) 与 markdown 有关的项目，使用 github 自带的搜星功能只能找到一个叫 miclle/Markdown-Editor 的项目，因为 github 是通过项目的名字进行搜索，这导致很多与 markdown 有关的项目被忽略了，但是使用 Gstar 搜索 markdown 能找到 11 个与 markdown 有关的项目，因为 Gstar 对项目名和项目描述都进行搜索，这样比 github 更准确些。

github 的搜星：

gstar 的搜星：

2.可以修改项目的描述 (description)，实现类似于打标签的功能

比如说我给 karmi/tire 这个项目的描述加上"搜索"，那么我就可以通过搜索"搜索"找到 tire 这个项目了。

3.自动更新 starred projects

Gstar 自带一个定时任务，每一分钟会去 github 那检查是否有新的 stars，如果有就会拉到本地，建立索引，方便你以后搜索使用。

参考资料

ruby 正则匹配中文

sequel 相关知识

angular js 分页

Description,一个通过分析 ActiveRecord::Migration 文件提取数据库文档的工具

kayakjiang — Sat, 31 Aug 2013 11:36:29 +0800

花了半个多月的时间写了个小工具 Description, Description 能对你的 rails 项目的 ActiveRecord::Migration 文件进行分析，然后得到和项目有关的数据库文档

安装

git clone https://github.com/baya/description.git cd description bundle install

使用

在 description 目录下执行 chmod +x bin/describle bin/describle /path/to/your/rails/app 然后使用浏览器访问 http://localhost:9393

主要功能

1.提取 migration 文件中的 comment，比如你创建一个表 contests，

    class CreateContests < ActiveRecord::Migration
    def change
      create_table :contests do |t|
        t.integer    :itype, default: 0, null: false  # 比赛形式, 0 photo, 1 video, 2 word, 3 audio, 4 组合
        t.integer    :mode, default: 0, null: false   # 是否可加入比赛, 0 pk, 1 调查, 2 多选
        t.integer    :format, default: 0, null: false # 比赛方式, 1 pk, 0 binary(传统比赛)
        t.date       :start_day                       # 比赛开始日期
        t.integer    :length                          # 比赛时长以天为单位
        t.integer    :vote_right                      # 投票权, 0 public, 1 friends only, 2 specific
        t.integer    :contestant_right                # 参赛权, 0 public, 1 friedns only, 2 specific
        t.string     :logo                            # 比赛logo,图片
        t.timestamps
      end
    end
end

然后在后面的开发中有增加字段或者重命名字段，

class AddStatusToContests < ActiveRecord::Migration
   def change
      add_column :contests, :pub_status, :integer, default: 0 # 发布状态, 0 草稿, 1 发布
   end
end

description 会将你的代码解析成一个 markdown 格式的 table,

2.快速检索表和字段有些项目的表很多，表很大，在 description 中，你可以通过表名和字段名快速找出你想要查看的表和字段

3.提供表的 markdown 文件的下载

结合 mou 等工具你可以很容易制作出十几页的项目文档，从此你就不需要为项目交接时的文档发愁了

后记

这个小工具完全是为自己的工作需要而开发的，觉得有用 (至少对我自己来说)，就分享出来了。我主要用 activerecord，所以没有提供其他 orm 框架的支持了。

聊聊 Ruby 中的 block, proc 和 lambda

kayakjiang — Mon, 22 Apr 2013 22:03:17 +0800

做为热身，从一些简单的例子开始，

def f1
  yield
end

def f2(&p)
  p.call
end

def f3(p)
  p.call
end

f1 { puts "f1" }

f2 { puts "f2" }

f3(proc{ puts "f3"})

f3(Proc.new{puts "f3"})

f3(lambda{puts "f3"})

若你用的是 ruby1.9 及以上的版本，还可以这样，

f3(-> {puts "f3"})

上面是 block, proc 和 lambda 的一些基本用法。

block

先说说 block, ruby 中的 block 是方法的一个重要但非必要的组成部分，我们可以认为方法的完整定义类似于，

def f(零个或多个参数, &p)
  ...
end

注意&p 不是参数，&p 类似于一种声明，当方法后面有 block 时，会将 block 捕捉起来存放到变量 p 中，如果方法后面没有 block，那么&p 什么也不干。

def f(&p)
end

f(1)  #=> 会抛出ArgumentError: wrong number of arguments (1 for 0)异常

f()  #=> 没有异常抛出

f() { puts "f"} #=> 没有异常抛出

从上面代码的运行结果可以知道&p 不是参数

def f(a)
  puts a
end

f(1) { puts 2}  #=> 没有异常抛出，输出1

所以任何方法后面都可以挂载一个 block，如果你定义的方法想使用 block 做点事情，那么你需要使用 yield 关键字或者&p

def f1
  yield
end

def f2(&p)
  p.call
end

此时 f1, f2 执行时后面必须挂一个 block，否则会抛出异常，f1 抛出 LocalJumpError: no block given (yield) 的异常，f2 抛出 NoMethodError: undefined method 'call' for nil:NilClass 的异常，ruby 提供了block_given?方法来判断方法后面是否挂了 block，于是我们可以这样修改 f1 和 f2，

def f1
 yield if block_given?
end

def f2(&p)
  p.call if block_given?
end

这样的话，f1 和 f2 后面无论挂不挂 block 都不会抛异常了。我们再来看看 f2 修改前抛出的 NoMethodError: undefined method 'call' for nil:NilClass 异常，这种说明当 f2 后面没有挂 block 的时候 p 是 nil，那么我们给 f2 挂个 block，再打印出 p，看看 p 究竟是什么，

def f2(&p)
  puts p.class
  puts p.inspect
  p.call
end

f2 {} # 输出Proc和类似<Proc:0x007fdc72829780@(irb):21>

这说明 p 是一个 Proc 实例对象，在 ruby 中，&还可以这么用，[1,2] & [2,3] 或者 puts true if 1 && 1 或者在某个类中将它作为一个方法名。

很多 ruby 老鸟会写类似下面的代码，

["1", "2", "3"].map(&:to_i)，其效果和["1", "2", "3"].map {|i| i.to_i }一样，但简洁了许多，并且更加拉风。这里的魔法在于符号&会触发:to_i 的 to_proc 方法，to_proc 执行后会返回一个 proc 实例，然后&会把这个 proc 实例转换成一个 block，我们需要要明白 map 方法后挂的是一个 block，而不是接收一个 proc 对象做为参数。&:to_i 是一个 block，block 不能独立存在，同时你也没有办法直接存储或传递它，必须把 block 挂在某个方法后面。

:to_i 是 Symbol 类的实例，Symbol 中的 to_proc 方法的实现类似于，

class Symbol

  def to_proc
    Proc.new {|obj| obj.send(self) }
  end

end

同理我们可以给自己写的类定义 to_proc 方法，然后使用&耍下酷，比如，

class AddBy

  def initialize(num = 0)
    @num = num
  end

  def to_proc
    Proc.new {|obj| obj.send('+', @num)}
  end

end

add_by_9 = AddBy.new(9)
puts [1,2,3].map(&add_by_9) #输出 [10, 11, 12]

在 ruby 中，block 有形，它有时候是这样

do |...|
  ...
end

有时候是这样

{|...| ...}

或者类似 &p, &:to_i, &add_by_9 之类，但是它无体，无体的意思就是说 block 无法单独存在，必须挂在方法后面，并且你没有办法直接把它存到变量里，也没有办法直接将它作为参数传递给方法，所以当你想存储，传递 block 时，你可以使用 proc 对象了，

 p = Proc.new(&:to_i)
 p = Proc.new {|obj| obj.to_i } 
 p = Proc.new do |obj|
   obj.to_i
 end
 p = proc(&:to_i)
 p = proc {|obj| obj.to_i}
 p = proc do |obj|
   obj.to_i
 end

def make_proc(&p)
  p
end

p = make_proc(&:to_i)
p = make_proc do |obj|
  obj.to_i
end
p = make_proc {|obj| obj.to_i }

虽然我在开发中经常用到 block，但是我很少显式地去使用 Proc 或 proc 去实例化 block，比如我几乎没有写过这样的代码，

f(Proc.new {|...| ...})

f(proc {|...| ...})

p =  Proc.new {|...| ...} #然后在某个地方p.call(...)或者将p传递给某个方法，比如f(p)

在使用 block 时，我会忽略 proc 的存在，我将 proc 定位为一个幕后的工作者。我经常写类似下面的代码，

def f(...)
  ...
  yield
  ...
end

def f(..., &p)
  ...
  p.call
  ...
end

def f(..., &p)
  instance_eval &p
  ...
end

def f(..., &p)
  ...
  defime_method m, &p
  ...
end

有些新手会写类似下面的一执行就会报错的代码，

def f(..., &p)
  instance_eval p
end

def f(..., p)
  instance_eval p.call
end

也有这样写的，

def f(..., &p)
  instance_eval do
    p.call
  end
end

或者

def f(...)
  instance_eval do
    yield
  end
end

我甚至写过类似下面的代码，

def f(...)
  instance_eval yield
end

我们经常在该挂 block 的时候，却把 proc 对象当参数传给方法了，或者不明白&p 就是 block 可以直接交给方法使用，我曾经也犯过这样的错误就是因为没有把 block 和 proc 正确的区分开来，&p 是 block, p 是 proc，不到万不得已的情况下不要显式地创建 proc，每当我对 block 和 proc 之间的关系犯糊涂时，我就会念上几句。

再来聊聊 yield 和&p，我们经常这样定义方法，

def f(...)
  yield(...)
end

def f(..., &p)
  p.call(...)
end

yield 和 call 后面都可以接参数，如果你是这样定义方法

def f(...)
  yield 1, 2
end

那么可以这样执行代码，

f(...) do |i, j|
  puts i
  puts j
end

但是这样做也不会有错，

f(...) do
  ...
end

p.call(...) 的情况类似，也就是说 block 和 proc 都不检查参数 (其实通过 proc 方法创建的 proc 在 1.8 是严格检查参数的，但是在 1.9 及以上的版本是不检查参数的)，为什么 block 和 proc 不检查参数呢？其实这个很好理解，因为在实际应用中你可能需要在一个方法中多次调用 block 或者 proc 并且给的参数个数不一样，比如，


def f()
  yield 0
  yield 1, 2
end

def ff(&p)
  p.call 0
  p.call 1, 2, 3
end

f do |a1, a2, a3|
  puts a1   
  puts a2
   puts a3
end

由于方法后面只能挂一个 block，所以要实现上面的代码功能，就不能去严格检查参数了。

转入正题，这两种方式效果差不多，都能很好地利用 block。使用 yield，看起来简洁，使用&p，看起来直观，并且你可以将&p 传给其他方法使用。但是在 ruby1.8 的版本你不应像下面这样做，

def f1(...)
  eval("yield")
end

可以，

def f2(..., &p)
  eval("p.call")
end

f1(...) {}  # 会抛异常
f2(...) {}  # 正常运行

当然上面这种用法很少见，但是却被我碰到了，我经常写一些方法去请求外部的 api，有时这些外部的 api 不是特别稳定，时不时会遇到一些 bad respoense, timeout 错误，针对这些错误，应该立即重发报文重试，对于其他异常就直接抛异常。于是我写了一个 try 方法来满足这个需求，


  def try(title, options = { }, &p)
    ee = '#{e}'
    tried_times = 0
    max_times = options[:max_times] || 3
    exceptions = options[:on] || Exception
    exceptions = [exceptions] if !exceptions.is_a?(Array)
    rescue_text = <<-EOF
      begin
        p.call
      rescue #{exceptions.join(',')} => e
        Rails.logger.info("#{title}发生异常#{ee}")
        if (tried_times += 1) < max_times
          Rails.logger.info("开始重试#{title}--第#{tried_times}次重试")
          retry 
        end
        raise e
      end
    EOF
    eval rescue_text
  end

try('某某api', :max_times => 2, :on => [Net::HTTPBadResponse, Timeout::Error]) do
  open(api_url)
end

最开始我用的是 yield，结果在 ree 下执行 try 方法时会报错，后来改成使用&p 就通过了。

通过试验发现在 ruby1.9 及以上版本已经没有这种差异了。

做个小结， block 和 proc 是两种不同的东西，block 有形无体，proc 可以将 block 实体化，可以把&p 看做一种运算，其中&触发 p 的 to_proc 方法，然后&会将 to_proc 方法返回的 proc 对象转换成 block 。

其中 proc 对象的 to_proc 方法返回自身。

p = proc {}
p.equal? p.to_proc  # 返回true

lambda

lambda 是匿名方法，lambda 和 proc 也是两种不同的东西，但是在 ruby 中 lambda 只能依附 proc 而存在，这点和 block 不同，block 并不依赖 proc。

l = lambda {}
puts l.class

在 ruby1.8 中输出的信息类似#Proc:0x0000000000000000@irb):1( 在 ruby1.9 及以上版本输出的信息类似#Proc:0x007f85548109d0@irb):1lambda)(，注意 1.9 及以上版本的输出多了 (lambda)，从这里可以理解 ruby 的设计者们确实在有意的区分 lambda 和 proc，并不想把 lambda 和 proc 混在一起，如同 ruby 中没有叫 Block 的类，除非你自己定义一个，ruby 中也没有叫 Lambda 的类，于是将 lambda 对象化的活儿就交给了 Proc，于是令人头大的情况出现了，当你用 lambda 弄出了一个匿名方法时，发现它是一个 proc 对象，并且这个匿名方法能干的活，proc 对象都能做，于是我们这些码农不淡定了，Proc.new {}这样可以，proc {}这样也没有问题，lambda {}这样做也不错，->{}这个还是能行，我平时吃个饭都为吃什么左右为难，现在一下子多出了四种差不多的方案来实现同一件事情，确实让人不好选择，特别是有些码农还有点小洁癖，如果在代码里一会儿看到proc{}, 一会儿看到lambda{},这多不整洁啊，让人心情不畅快。在这里我们认定 lambda 或者 -> 弄出的就是一个匿名方法，记做 l, 即使它披着 proc 的外衣，proc 或者 Proc.new 创建的就是一个 proc 对象，记做 p 在 ruby 各个版本中，l 和 p 是有一些差别的。

定义一些方法，


def f0()
  p = Proc.new {return 0}
  p.call
  1
end

def f1()
  p = proc { return 0 }
  p.call
  1
end

def f2()
  l = lambda { return 0}
  l.call
  1
end

def f3(p)
  instance_eval &p
  1
end

class A
end

def f4(p)
  A.class_eval &p
  1
end

p1 = Proc.new { }
p2 = proc {}
l  = lambda {}

def f5()
  yield 1, 2
end

f5 {}
f5 {|i|}
f5 {|i,j|}
f5 {|i,j,k|}

lambda 和 proc 之间的区别除了那个经常用做面试题目的经典的 return 之外，还有一个区别就是 lambda 不能完美的转换为 block(这点可以通过 f3 和 f4 执行的过程得证)，而 proc 可以完美的转换为 block，注意，我说的 lambda 指的是用 lambda 方法或者->符号生成的 proc，当然和方法一样 lambda 是严格检查参数的，这个特点也和 proc 不一样。

从上面的数据对比来看，在 1.8 版本，lambda 和 proc 方法生成的 proc 对象的行为是一致的，但在 1.9 以上和 jruby 的版本中，lambda 和 proc 的不同处增多，可以认为 ruby 的设计者们并不想把 lambda 和 proc 混同为一件事物。如我前面所讲，proc 的主要作用是对象化 block 和 lambda，并且 proc 在行为上更接近于 block。

retrun 的几个试验


def f0()
  p = Proc.new { return 0}
  p.call
  1
end

def f1()
  l = lambda { return 0}
  l.call
  1
end

f0 # 返回0
f1 # 返回1

如果你能够理解 proc 在行为上更像 block，lambda 其实就是方法只不过是匿名的，那么你对上面的结果不会感到惊讶。

如果把 f0,f1 做一些修改，就更容易理解上面的结果了。


def f0()
  return 0
  1
end

def f1()
  def __f1
    return 0
  end
  __f1
  1
end

f0 # 返回0
f1 # 返回1

return 只能在方法体里执行，


p = Proc.new { return 0 }
l = lambda { return 0 }

p.call # 报LocalJumpError
l.call # 返回0

构造 p 的时候我没有使用 proc {return 0}，因为在 ruby1.8 中，proc {return 0}的行为和 lambda 一样，比如在 ruby1.8 中，


def f(p)
  p.call
  1
end

p = proc { return 0 }
l = lambda { return 0 }

f(p)  # 返回1
f(l)  # 返回1

p.call # 返回0
l.call # 返回0

def f(p)
  p.call
  1
end

p = Proc.new { return 0 }
l = lambda.new { return 0}

f(p)  # 报LocalJumpError
f(l)  # 返回1

我感觉 proc 中的 return 能记住 proc 生成时其 block 的位置，然后无论 proc 在哪里调用，都会从 proc 生成时其 block 所在位置处开始 return，有下面的代码为证：


def f(p)
  p.call
  1
end

def f2()
  Proc.new { return 0 }
end

def f3()
  lambda { return 0 }
end

p = f2()
l = f3()

f(p)  # 报LocalJumpError: unexpected return，from (irb):29:in `f2'
f(l)  # 返回1

我在 1.8, ree, jruby, 1.9, 2.0 各版本都测试过，结果一样。

再看看下面的代码，


def f0(&p)
  p.call
  1
end

def f1()
  yield
  1
end

f0 { return 0}  # LocalJumpErrorw
f1 { return 0}  # LocalJumpErrorw

f0(&Proc.new{return 0}) # LocalJumpError
f0(&lambda{return 0})   # 返回1

def f2(&p)
  p
end

def f3()
  p = f2 do
    return 0
  end
  p.call
  1
end

f3 # 返回0

我们重点看看 f3 中的 proc p，它虽然是从 f2 中生成返回的，但是 p 生成时其 block 是处在在 f3 的方法体内，这个类似于，


def f3()
  p = Proc.new { return 0}
  p.call
  1
end

所以执行 f3 时，没有异常抛出，返回 0。

总结

当你想写出类似于 f do ...; end 或者 f {...}的代码时，请直接使用 block，通过 yield, &p 就能达到目的，当你想使用 proc 时，其实此时绝大部分的情况是你实际想用 lambda，请直接使用 lambda{}或者->{}就可以了，尽量不要显示地使用 Proc.new{} 或者 proc{}去创建 proc。

废话说了一大堆，其实我最想说的是：用 block，用 lambda，不要用 proc，让 proc 做好自己的幕后工作就好了。

kayakjiang (jgm)

那种表名是业务 +日期的表你们会用 AR 去查询吗?

去他的 RTFM, 只要 @kayakjiang 我有问必答，绝不敷衍

RubyConf China

李笑来的全栈营

我的有问必答

怎样在技术论坛里对技术问题进行高效沟通

微信小程序开发和 Rails 开发的相似之处

微信小程序和 Rails 程序的相似之处

微信小程序练习预览

35 * 2 = 70

Web 安全和 Rails

XSS

见招拆招

招数#0 Never Insert Untrusted Data Except in Allowed Locations

招数#1 HTML Escape Before Inserting Untrusted Data into HTML Element Content

招数#2 Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

招数#3 JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values

招数#3.1 HTML escape JSON values in an HTML context and read the data with JSON.parse

招数#4 CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values

招数#5 URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

招数#6 Sanitize HTML Markup with a Library Designed for the Job

招数#7 Prevent DOM-based XSS

加强版招数#1 Use HTTPOnly cookie flag

加强版招数#2 Implement Content Security Policy

试验一 script-src 'none'

试验二 script-src 'self'

试验三 script-src 'self' ${EXTERNAL-SCRIPT-LIST}

试验四 script-src 'self' 'nonce-$RANDOM'

试验五 script-src 'unsafe-inline'

试验六 default-src 'self'

试验七 script-src 'unsafe-eval'

试验八 Content-Security-Policy-Report-Only: default-src 'self'

CSRF

模拟 CSRF 攻防

用例 1

用例 2

用例 3

Session Fixation

Brute Force Attack

参考

试验用到的代码

XSS

HTTPOnly

Content Security Policy

大规模 I18n 实践

问题概述与挑战

1. 使用 redis 作为翻译的存储后端

1.1 建立 redis.yml 文件

1.2 建立 locales.yml 文件

1.3 配置 redis 为翻译的存储后端

1.4 调试 I18n 是否正常工作

1.4.1 将 zh-s-CN.yml 导入到 redis

1.4.2 进入 rails console 调试

2. 用户线上提交翻译

2.1 标准化用户输入

2.2 写代码

特例：邮件的翻译

使用 Rails 构建 API 实践

加入第一个 API resource

BaseController

配置路由：

Api::V1::UsersController

User 模型和 users 表

增加认证 (Authentication)

给 User 模型增加 authentication_token 属性

生成 authentication_token

sessions endpoint

给 User 模型增加和 password 相关的属性

给数据库中已存在的测试用户增加密码和 authentication token

实现和 current_user 相关的方法

实现 app/views/api/v1/sessions/create.json.jbuilder

配置和 sessions 相关的路由

Authenticate User

增加授权 (Authorization)

安装 pundit

创建和 user 相关的权限机制

使用 UserPolicy

分页

建立 Micropost 模型

试验一 `script-src 'none'`

试验二 `script-src 'self'`

试验三 `script-src 'self' ${EXTERNAL-SCRIPT-LIST}`

试验四 `script-src 'self' 'nonce-$RANDOM'`

试验五 `script-src 'unsafe-inline'`

试验六 `default-src 'self'`

试验七 `script-src 'unsafe-eval'`

试验八 `Content-Security-Policy-Report-Only: default-src 'self'`

使用 `UserPolicy`