罗泽轩

最近发生一件事， [Ruby-China Mongodb注入可导致盗用管理员(他人)身份发帖](http://wooyun.org/bugs/wooyun-2014-086474)引起了我的兴趣。 具体内容可以移步到链接去看。随便给出对应的pr地址：https://github.com/ruby-china/ruby-china/commit/ff19cc1fb6d9ea8b0109d7f62741f6652009ff3d 于是我搜索了相关资料，以搬运工的身份写下这篇文章。 ## MongoDB， no SQL injection? 有人的地方就有江湖，有DB的地方就有injection。SQL数据库如此，No SQL数据库亦是如此。考虑到No SQL数据库用的不是SQL，这里使用SQL injection是否有点不太恰当？不过总不能说是No SQL injection吧XD。 言归正传，OWASP上面有一篇文章， https://www.owasp.org/index.php/Testing_for_NoSQL_injection， 讲到MongoDB的注入问题。另外，[MongoDB官方文档FAQ](http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection)中也提到对于SQL injection的防范方式。其他地方提到的资料基本上大同小异。 根据上面两份资料的内容，以及其他在网上找到的内容： 1. No SQL不代表安全。由于No SQL使用的查询语言很多是过程式语言而非声明式语言，No SQL注入的危害甚至比传统的SQL数据库更大。 2. 不要草率地通过拼接用户输入的方式来生成查询语句。这个就不需要举例吧，了解MongoDB查询语言的人，应该可以想象到会是什么结果。 3. 好消息：MongoDB会在driver中将查询字符串编码成BSON格式。类似于`,:{`这样的奇奇怪怪的符号会导致BSON构造出错。这样cracker在注入时需要花费更多的心思了。...

最近一个月来，我追完了Fate Stay Night fate线动画全部24集，外加各种特典，另外重看了部分片段。（吾王万岁！）真是非常棒的说！等UBW线完结后，我会第一时间去补UBW动画的！ 看完感觉：超爱Saber！（我也希望会有一个像Saber那样坚毅、勇敢又善良的女朋友）不过，最后士郎和Saber没有能够在一起，“虽然看上去那么近，但是伸手却抓不到”，看到这里我整个人都不舒服了。完全一种淡淡的忧伤的感觉，即使最终打败了Boss，有情人终难免永别……本来希望编剧能够有个神来之笔，用魔法让Saber复活。不过应死之人终究会走入死亡，Saber还是回到她来的时空，安详地魂归Avalon。 另外，尽管动画中没有说明，根据游戏的设定，伊莉雅也只剩下一年的生命了……虽然结尾的时候她还是那般精神奕奕，但是作为人造人，短暂的生命就像诅咒一样，无形地压在命运上。多可怜啊，这么一个可爱的萝莉。（其实人家不是萝莉！只是8岁之后就停止生长了。人家是切嗣的女儿，士郎的姐姐，年纪在一帮高中生中是最大的。嗯，ACG当中真是无限可能。） 圣杯战争是，被选中的魔法师们为了争夺可以实现愿望的圣杯而进行的互相争斗。同样是讲述不真实的生存游戏，圣杯战争的概念就比《饥饿游戏》好的多。虽然《饥饿游戏》扯上了反压迫的大道理，不过比起Fate Stay Night中的故事，未免显得太过平平。有趣的是，动画的结尾不是好人从坏人手中夺取圣杯，然后世界重新恢复爱与和平。那样就成了中二病动画…… 事实上，圣杯只是诱饵，可怜的魔法师们，只是一场仪式所不能缺少的部分。当圣杯出现在人们的眼前，人们才知道，原来一直苦苦追求的东西，其实是“恶”之化身。于是，切嗣也好，士郎也好，最后都选择破坏圣杯。不同的是，切嗣需要对抗的，只是之前对于圣杯的渴望；而士郎一旦选择破坏圣杯，就是选择结束圣杯战争，也即结束Saber的使命（寿命）。最后，Saber说，“我希望听到你的声音”，士郎下定了决心，命令Saber发动誓约胜利之剑，向圣杯划出一击…… 让我们回过来看看圣杯御三家，爱因贝兹、间桐和远坂。为了圣杯，这三家每60年就会进行杀戮和被杀戮，结果是为了追求一种灾难，真是家族的不幸。如果看了HF线的剧情（还有Fate Zero的），就难免为他们三家的不幸而感到惋惜。 最后看看动画中第二对未能成眷属的有情人，caster和葛木。在Fate线中这对戏份不多，很多事情都没有交代，给人一种坏蛋情侣最终双双死去的感觉。不过caster临死前那句，“我的愿望，截止到现在，一直都是实现的”，-- 跟心爱的人在一起，就是这么难么 -- 真是让人不禁心里泪落。其实Caster追求圣杯，也许是追求圣杯期许的第二生命，否则就不能活下来跟心爱的人在一起了。可惜人算不如天算，幕后Boss早已安排了一切，原以为大事即将完成，结果半路杀出强敌，反而丢了卿卿性命。

MiniTest是什么？不懂的请搜索一下，我就不解释了。 在MiniTest之前，用Ruby做测试的有两种人，一种人喜欢Test::Unit的`test_*`风格，另一种人喜欢Rspec的`describe`风格。他们时不时因为这两种风格的优缺点以及哪一方才能代表真正的Ruby测试风格而争执不下。（这有点像《格列佛游记》中，两个小人国因从哪个方向打碎蛋壳而反目成仇） 后来，MiniTest出现了，改变了这一切。MiniTest向众人宣讲道，“汝可择Test::Unit之道而从之，亦可择Rspec而从之”。在MiniTest里，你可以像Test::Unit那样写测试，也可以像Rspec那样写测试。是故，MiniTest用一种包容的心态解决了纷争，重新给世界带来了和平。 这篇文章，就是讲讲MiniTest的正确使用姿势。 ## Hello World 使用了MiniTest的测试代码像这样： ``` ruby require 'minitest/autorun' # 注意有些资料中，测试类不是继承自MiniTest::Test， # 那是MiniTest 5之前的做法，MiniTest会通知你改正 class TestMyLife < MiniTest::Test # 这个方法会在各个测试之前被调用 def setup @me = People.new end def...

原文见此：https://developer.yahoo.com/performance/rules.html **注意，不是翻译，只是谈谈本人的读后感。** **另外注意，该文比较旧，大概是2010年的产物，所以里面会有些跟不上时代的内容。** ## 1. 减少HTTP请求 一个典型的http请求报文大概是这样的： ``` GET /3.3.0/build/yui/yui-min.js HTTP/1.1Host: yui-s.yahooapis.com Pragma: no-cache Cache-Control: no-cache... ``` 虽然也就几行文字，但是考虑到http协议里，对同一个域名同时发出的请求是受限的[[1]](http://www.zhihu.com/question/20474326)，如果请求太多，说不定它们会堵塞在队列中呢。哦，对了，忘记把cookie算上去了，每次请求的时候都会附带当前域下的cookie，有时候关这一项就有几百B呢。 解决方法： 1. 文件打包使用[CSS Sprites](http://www.qianduan.net/useful-to-create-a-simple-css-sprites.html)： 将小图标们合并成一幅大背景图，再通过恰当地设置`background-image`和`background-position`来取出。根据你所用的语言和框架，一般都能找到相关的工具来完成这一任务。除了可以打包图片，还可以打包css文件和js文件。把多个相关js文件和css文件打包成单一的js文件或css文件，省下的http请求数量。这也可以交由工具去做。比如Flask可以使用[Flask-Assets](http://flask-assets.readthedocs.org/en/latest/)。 2. 内联图片可以用[data: URL](https://developer.mozilla.org/zh-CN/docs/data_URIs)模式来内联图片。比如Github 404页面上的几幅图片：https://github.com/404 ## 2. 使用CDN...

标题是借鉴于某鸡汤……原文在此：https://zapier.com/blog/best-ways-work-smarter-not-harder/ 不是翻译，只是写个读后感。 ## 1. 停止多任务 多任务使人产生一种“我今天做了很多事”的幻觉，正如多任务计算机使用户产生自己独占了整个计算资源的幻觉一样。 今天，大部分的操作系统都是支持多任务的，这让人以为多任务是一种先进的特性，支持多任务的操作系统能够在单位时间中完成更多的工作。实际上，支持多任务的操作系统，效率并不比不支持多任务的操作系统要高。之所以要支持多任务，是因为它们需要跟人交互，而只有能够在任务间流畅切换，才能及时响应人的各种指令。 据说，由于任务间切换需要花费大量的时间和空间进行上下文切换，支持多任务的操作系统需要付出4%的性能。这个数字可能不准确，不过多任务的确降低了操作系统的效率，而非提高。人也一样。 ## 2. 多休息 90分钟的工作配15到20分钟的休息……呃，这个因人而异吧。我就是经常坐不定O(∩_∩)O。 要想多休息，建议把水杯放远点，这样就能多休息了。（或者使用编译型语言，参照那个xkcd的[老梗](http://xkcd.com/303/)） ## 3. 提前做一周计划 ## 4. 批处理同类任务 这一条正好是跟第一条相对照的，批处理同类任务减少了在不同任务间切换的开销。 ## 5. 根据你的精力调度任务 计划安排要考虑自己的体质特性。或许可以像记录生理周期一样记录自己在一天中通常的精力变化。 ## 6. 裁剪to-do表 保持小步快走 ## 7....

在用Backbone两次之后，我终于无法忍受它的原始和简陋。虽然Backbone不是一个SPA框架，而只是个javascript的MVC框架罢了。以SPA框架去强求它，的确是不公平的。不过，我还是渴望用一个可以绑定DOM的SPA框架。 在用Backbone编程的时候，你需要把代码划分为model和view两层。虽然Backbone声称是MVC（Model View Collection）框架，但是Collection其实也应该划分到Model类别中。 Model层负责放置数据，而view层负责展示数据和接受用户的操作事件。在这里，view层相当于一般的MVC架构中controller加view的组合。当然，在这样的组合中，就不要指望将view和controller分离了。不过这个不是我现在要吐槽的问题。问题是，controller无法**自动**地更新view。 让我们看看Backbone中model和view是怎么协作的。首先view接收事件，然后修改绑定的model，再用model的数据更新页面（或者由model驱动被绑定的view更新）。这样一来，controller的更新，就依赖于model层对脏数据的处理了。model层在产生脏数据之后，**必须**去触发view层更新。如果没有及时更新，就会发生数据混乱的问题。所以，model层需要紧密地和view层绑定。每次model的数据改变后，都需要要相应的方法来改变对应的页面内容。这个方法既可以放在model层中，也可以放在view层之中。 结果是，对应于model的每个状态，都需要有对应的方法来更新页面。这么说来你需要写两套方法，一套方法来响应用户对页面的动作，并反馈给受绑定的model；另一套方法用于使用model层最新的数据，更新页面。哦对了，你还要手工绑定model和view，有时还需要双向绑定喔。这么多方法，不但写起来麻烦，维护起来也麻烦。 如果SPA框架可以绑定具体的DOM，然后由此实现对应的MVC，那该多好呀！ 这么一来，不但立刻有了现成的接口可用，而且SPA带来的页面不会刷新的问题也能解决了。再也不需要在view层中显式记录当前DOM的状态了，只需要交由框架自动处理了。view层的职责又能卸下一大块。 如果能更进一步，以前端的每一个model对应后台的每一个model，然后可以像定义路由表一样定义model的方法，调用该方法自动调用同名的RESTful 方法，那就更加方便了，不再需要依靠少的可怜的几个同步方法，不再手工写$.ajax了。

先给几个数据： ``` C++ cout

这是chrome devtool技巧的最后一篇了……写完这篇算是填了坑。说好的花几天看看呢，其实花了整整半个月了。 这一篇讲的是devtool中的debug技巧。 ## debug技巧 debug之道，在于运气，在于淡定；debug之术，在于断点触发，在于定格上下文。 debug之道，道可道，非常道，名可名，非常名。本人吹水水平不高，所以不可能从道的角度上指点江山，只能在具体的术上激扬文字，呃不，扯上几句。 何为断点触发？chrome devtool中提供了普通断点，条件断点，DOM断点和XHR断点这四种断点，基本上无论JS中要执行什么代码，都会有合适的断点用得上。（除非绑定了外面的C++ add-on，不过一般都不会遇到这种问题） 何为定格上下文？当断点被触发时，你就会停下来。这时候会出于一个上下文环境中，在右侧的框中能够查看当前所有的变量，还可以在call stack中查看前面的函数调用。甚至可以在下面的console面板（你可以把它拖上来）中执行各种上下文可用的函数（如果引入了underscore或jQuery，就能直接执行underscore之类的js库的函数哦）。 下面详细介绍下这两个方面。 ## 断点触发 条件断点：正常断点 》 右键菜单 》 Edit breakpoint，添加表达式，当表达式为true时使断点生效。条件断点的颜色为橙色 异常断点：右边最顶上一栏，最后一个像插座的按钮，可以选择是否在（未捕获）异常发生时触发断点 DOM断点：前面关于Element面板那一章说了。这里可以查看都设置了哪些DOM断点 XHR断点：当出现URL匹配的请求时，触发断点。URL模式为空时，匹配所有请求 ## 定格上下文 定格上下文所需的，要找到对应的stack。在chrome中，我们甚至可以让devtool显示之前异步的调用（XHR或timeout事件触发），只需勾选右边的Async选项即可。 有趣的是，在call stack中，如果选择不同的stack，console的上下文也会跟着改变。可以试一下在不同的stack中打印this的值，你会发现不同的stack输出结果会不一样。这意味着，**call stack中不仅可以反应当前上下文，还可以切换过往的上下文。**...

这一次讲的是关于network、profile等内容。简而言之，就是讲各种杂项。既然讲的是杂项，说的也自然难以找到一个主题。而且对于这些面板，实际上自己也没怎么用过，所以恐怕会讲得枯燥无味些。 ## network面板 没什么好说的……左边是请求的各项资源，右边是请求、响应所花费的时间。右边这一栏中，浅色的为浏览器请求花费的时间，深色的为服务器响应花费的时间。蓝色线为DOMContented事件发生的时间（就是DOM tree中各个元素已经各就各位的时候），这时候会触发JQuery中的$(document).ready()。而红色线是真正的load事件发生的时间，这时候各项资源已经加载完毕了。 有一个小技巧：在请求图标上右键菜单，可以选择copy as cURL，则能复制出对应的curl请求。（curl党有福了） ## timeline面板 可以录制某段时间内发生的浏览器事件，比如render、scroll之类。并显示其对应的开销。 在这里可以清晰地显示浏览器在进行解析html之类的操作所花费的时间和消耗的CPU资源等等。优化强迫症患者必备。 另附：用鼠标滚轮可以放大/缩小所在的区域。 ## profile面板 点击录制按钮，开始录制CPU开销，或者给heap上分配的内存来个快照。 CPU开销这个基本没有过。给heap上分配的内存拍快照，则有些用途，据说可以查明JS内存泄露的问题。 #### JS内存泄露 在V8中，除了普通的Number类型（4个byte）和某些特殊的存储在JS VM之外的对象，其他所有的对象都分配在heap上。 这些被分配的对象互相引用，构成了一个图。 假如我们把某个对象当做GC的根对象，那么就可以给其他对象设定一个距离。而所有的互相引用的对象也可以看做一棵树。 不过这里不需要懂得多少概念，因为我们很快就要进入主题 —— JS的内存泄露 —— 了。 如果我们定义内存泄露为“一定时间内存在无法访问但是占据了内存的对象”， 那么有GC的语言也是会发生内存泄露的。...

Elements可能是大家见过次数最大的面板了，因为每次审查元素都会打开它。 所以这一次来讲讲Elements面板中可用的小技巧。 Elements面板可以分成两块，左边的显示html源码，右边的显示各种相关的属性，默认是显示对应dom元素的style。 那么先从左边开始： ## html源码框 右键菜单，你能看到许多有用的选项。复制、将选择的dom元素置于某种状态什么的不说了。有一个“Scroll into view”选项，可以将页面滚动到鼠标所在/选中的DOM节点上。还有一个“Break on”，弹出子菜单中可以选择断点类型。可以选择DOM元素发生何种变化时会触发一个断点。该断点一旦被触发，就会跳转到Source面板中，进入debug模式。具体有哪些类型，菜单上已经写得一目了然了，这里不再赘述。 ## style框 看完左边的html源码框，让我们出门右转进入右边的style框。这个框显示的是选中的dom节点的具体css style。自上而下，分别是不同的css规则，按优先级先后排列。 一个重要的技巧是，如果你点击css右上角的url链接，就能跳转到Source面板中对应的文件。在这里Ctrl+s能够保存对css文件的修改。这意味着，如果在调试的过程中对css规则做了较大的修改，不需要跑到各个css规则中复制修改到源文件中，只需要跳到对应的Source面板下的css源文件中进行保存就行了。 还有一个有趣的地方，在颜色选择器中Shift+click，会改变颜色的表示方式，比如从#FFFFFF变为rgb(255,255,255)。对于强迫症患者，这个倒是个不错的功能呢。 ## Compute框 在Style框中查看DOM元素属性时，有时候会发现自己想要查明的属性值，居然要拉到最底下才看到，原来是被XX规则设定成这样了。 其实切换到隔壁Compute框就不用那么辛苦了。 Compute框中显示的是选中元素计算出来的最终属性。勾上`Show inherited properties`并配合`Filter`一起使用，生活一下子轻松了很多。 ## Event Listener框 如其名。这个框显示的是相关的event listeners。展开对应的event listener，可以看到若干个属性，其中有isAttribute，显示是否是通过DOM属性（如on系列）来设置的；还有useCapture，显示该`addEventListener`调用中设置的[useCapture](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.addEventListener) 值。其他还有别的什么属性，因为没有用到过，所以我直接忽略掉好了。...