str = "

\n
• One
\n
• Two
\n

puts str.inspect # => "

\n
• One
\n
• Two
\n

旧的不去新的不来，找个新的对象寄放和释放一下感情，慢慢把旧的给忘掉掉。至少也不要那么痛。

不要消沉地过日子，多主动参与集体活动，在集体活动中让自己的能力被别人肯定，慢慢找回自己的自信。

切忌沉迷烟酒或游戏。

#48 楼 @congteng #50 楼 @jasl @congteng 的资料里，注册日期好屌啊

#47 楼 @tumayun 已邀请～

#45 楼 @gaicitadie 做『后继有人』的感想。：）

#42 楼 @fresh_fish #43 楼 @kewin 没错...已经是赤裸裸地白热化歧视了...

#33 楼 @jasl 如果真的有这样的 group ...强烈求围观！！！

#36 楼 @lgn21st 以『为中国五年后的开源社区培养中流砥柱』为使命。：）

#28 楼 @x290431695 对的，而且这个列表搭建起来之后，一度有人想把人继续 fork 出去.....

#20 楼 @chunlea #22 楼 @tiseheaini 可以麻烦给多点资料吗？我一个个去人肉很痛苦诶....

#21 楼 @zgm 致青春了.....

#22 楼 @tiseheaini #20 楼 @chunlea 阅读你们的资料中...

#13 楼 @jasl 谢谢大牛赏识哈～

我正好想要主动联系一下同龄人但苦于没名单呢。赞！

#10 楼 @nightire 而且我觉得我在这里找到的同龄人应该也不缺与年长者交流的机会，所以一拍脑袋就这么决定只要同龄人了。：）

#8 楼 @jasl 下午体验过了，相当骚 -_-

#9 楼 @robin 牛人！已加。

#10 楼 @nightire 因为 V2EX 和 ruby-china 已经提供了供大家交流的平台，所以我希望这个邮件列表可以更针对我们刚开始找工作或是刚开始工作的年轻同学，他们有更多的话题可以聊。这只是一个缩小圈子增加话题的手段，并不存在排斥的问题。：）

比如下午就有同学在里面聊到了去北京实习的租房问题，因为他们都刚好在找实习。

and 这个邮件列表只排斥年龄大的，更小的倒是不排斥。说起来 00 后程序员我们也是欢迎的：）

#4 楼 @Alex 已邀请哈～

#1 楼 @jjym 现在也在求职哈～只不过想组个兴趣者团队～

#8 楼 @zgm #9 楼 @doitian zgm 大神，怪我没看清他的代码。我没想到他的代码在 print 后面也有空格....刚才我确认了一下，确实有。

这个问题的话，不管 1.9 还是 2.0 当然都不行哈。一旦方法名后面有了空格，那么空格之后的括号会作为一个整体被传入。而 Ruby 不像 Python 一样拥有一种叫 tuple 的数据类型，所以会报语法错误。 我在 pry 里面试了试， (1,2,3) 这个语句对于 Ruby 来说是个语法错误。

#5 楼 @DrinE 空格的问题.........是引号的问题。。。。

我目前在学校，电信封了路由器，而我的笔记本插不了网线，于是用的是校园网 Wi-Fi。我今晚想帮一个 Weibo API 项目提交点代码，发现 GitHub 上不去，于是作罢。

Chart.js ?

#7 楼 @KoALa #8 楼 @zgm 如果改用 redis 来存储的话，那么本地只会保存一个 session_id，其他的内容都会保存在 redis 里面，也就不存在暴露数据的问题了。不过我的看法是，用 Rails 原生的这个 CookieStore 都好了。理由如下：

1. 只要你没有暴露自己的 secret_token.rb，攻击者也是无法伪造的。
2. 速度快。
3. ruby-china 已经算是一个五脏俱全的站点了，它的 CookieStore 里面也只是保存了每个用户对应的 user_id 而已。如果你用了 devise 或者 warden 的话，那么这个 user_id 也是带指纹的，这么一来即使暴露了 secret_token.rb 也同样无法篡改这个 user_id。

不知我文中还有什么解释不清楚的地方，可以留言交流交流，我也是正在学习当中。：）

#1 楼 @jasl 好东西，收了！

#3 楼 @jjym 对的，Rails 毕竟『重』嘛～

#4 楼 @zlx_star 是可以成功的。因为 CookieStore 之所以效率高正是因为 session 的相关信息都存在了用户的浏览器这里，服务器那边因此就不必通过任何 database 就可以取到特定 session 的 data 了。

可是存在用户浏览器这里的 data（以 marshal 之后 的 hash 形式存在，并用 base64 编码）是没有加密的，于是用户可以随意改动。为了保持数据的完整性，Rails 就会在用户浏览器的 Cookie 中再保存一段 digest，到时候如果用户更改了 session data，那么 digest 就会不一致导致验证无法通过，从而确保完整性。

而这个 Cookie 中的 digest 是怎么算出来的呢？可以认为是通过一个函数，这个函数接受 session_data_hash 和 secret_token 两个参数。

当 session_data_hash 可以被改动，而 secret_token 又被泄漏时，那么只要按照上述的生成过程再次生成一下 Cookie 中的 digest，服务器就会相信浏览器这边改动后的新 session 了。毕竟服务器是没有保存任何相关信息的。

我来写篇博文发发吧～

Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).

独立开发者的 Web 开发学习成本真的很高啊....不仅前端后端，还要注意各种安全性问题。

以上提到的『适当的算法』在此：https://github.com/joernchen/evil_stuff/blob/master/ruby/sign-cookie.rb

ruby-china 的 secret_token.rb 在此：https://github.com/ruby-china/ruby-china/blob/master/config/initializers/secret_token.rb

我还原了一下 ruby-china 在我浏览器上设置的 session（抹掉了信息，只保留了格式）

{"session_id"=>"06fd9f57exxxxxxxxxxxxxxxxxxxx0dd", "_csrf_token"=>"eddCzjiFBIeGrrxxWxxxxxxxxxxxxxxxxxxxxps+Hxc=", "warden.user.user.key"=>["User", [1848], "$2a$10xxxxxxxxxxxxxxxKDX.YIpO"]}

首先 session_id 这关貌似就过不了。

_csrf_token 貌似在我们的话题中不是很必要。

warden.user.user.key 虽然表露出我在 User 表中，且 id 是 1848（我是 ruby-china 的 1848 号会员），但是 warden 在后面加了个 digest，所以也无法伪造。

很多时候，如果我们并没有 devise 或者 warden 这样的库的时候，我们会简单地保存 user_id 这个值在 session 中（用的时候，在服务端会取出 session[:user_id]）。在这样的情况下，如果不小心暴露了自己的 config/initializers/secret_token.rb 文件，那么，就可以简单地把 user_id 修改为其他人的，并通过适当的算法生成 CookieStore 生成的那个 digest，然后 do evil。

http://phenoelit.org/blog/archives/2012/12/21/let_me_github_that_for_you/index.html

这里有篇文章提到类似问题。

#7 楼 @Rei 这个链接好讽刺。。

#58 楼 @zzhattzzh 可能是因为之前被一家创业公司拒了之后，有点挫败吧....不过到了社区这里，发现还是有蛮多机会可以选择的，倒也柳暗花明又一村了。：）

#55 楼 @andor_chen 相对同龄人来说，真的敢这么说。

#56 楼 @lgn21st 找实习很艰难...于是只好上社区试试水...很多人都在这样找实习的嘛......