AJAX in Rails with Authenticity Token

这是一篇很重要的转载文章。

如何从Rails框架中全部去掉Authenticity Token 功能:

注释掉Application Controller中的protect_from_forgery语句。

When you use active_record_store instead of the cookie-based default, you need to uncomment the line in controllers/application.rb that says protect_from_forgery :secret => ‘blah’. This makes sure all your HTML and JavaScript requests are coming from your web application. It essentially protects you from something called “Cross-site request forgery” by embedding a token into your web forms.

As a side note, it’s really not giving you much security at all, but that might be better left for another blog post.

I was banging my head against the wall yesterday trying to figure out why a custom Ajax.Updater wasn’t working and I kept getting an ActionController::InvalidAuthenticityToken exception. I decided to dig into the request_forgery_protection.rb file in actionpack-*/lib/action_controller and found that for custom requests, you need to include the authenticity_token yourself by taking advantage of the form_authenticity_token helper. When building the updater’s request url I just added “&authenticity_token=<%= form_authenticity_token %>” to the end and everything was fine.

Another way would be to not use the forgery protection at all for that action by including this in your controller: protect_from_forgery :except => :updater

You can also completely remove forgery protection from a controller by doing skip_before_filter :verify_authenticity_token

Back to the vulnerability of your web forms: I imagine this does protect your web application from someone hosting a form on their site that posts to your site. However, if someone really wants to spam some stuff they’ll scrape your page with cookies enabled on their scraping software, scrape your form’s fields (which include the authenticity_token hidden field) and POST to their heart’s desire.

Oracle Mix: First large JRuby on Rails app online

http://www.infoq.com/news/2007/11/oracle-mix-jruby

Oracle Mix：网上第一个大型JRuby on Rails应用

作者 Werner Schuster译者 郭晓刚 发布于 2007年11月15日 下午9时7分

Oracle刚刚发布了名为Oracle Mix的社交网络Web应用——它用的是JRuby on Rails：

到目前为止对Oracle Mix的反响都是正面的。我要澄清一下Paul对Mix的技术架构的评论……它的运行环境是Oracle Application Server、Oracle Database、Oracle Internet Directory、Oracle SSO和JRuby on Rails。据我所知，Mix是首个也是最大型的面向公众的JRuby on Rails部署。最棒的是我们用了不到5周时间就实现了它……在ThoughtWorks的优秀人员的帮助下。

这是ThoughtWorks继Mingle和CruiseControl.rb之后涉足的又一个JRuby项目。JRuby团队成员以及ThoughtWorks员工Ola Bini也参与了Oracle Mix项目：

在之前的5个星期里，由我、Alexey Verkhovsky、Matt Wastrodowski和Toby Tripp几个来自ThoughtWorks的人，再加上来自Oracle的Rich Manalang，共同以一个Oracle内部应用为基础创建了一个新应用。这个网站叫做Oracle Mix，目标是作为Oracle的客户与Oracle以及客户之间相互沟通的途径，客户们还可以提出建议，回答彼此的问题以及建立一般的联系网络。

你在实际投入使用的系统中使用了JRuby on Rails吗？你会如何使用JRuby on Rails——是编写专门的JRuby应用，还是用它来运行已有的Rails应用？

Ruby Deployment and Scaling

Rails的部署与伸缩

在Rails发布的时候，选择发布平台是开发人员关心的问题。Rails可以在很多Web服务器上运行，只要实现了CGI协议的Web服务器都可以，这是Rails的最低。

　　　　　　　　容易部署　　　速度　　　　伸缩
WEBrick　　　　★★★★★　　★★　　　　　★
Apache-CGI　　　★★★★　　　★　　　　　★★
Apache-fcgi　　　　★　　　　★★★★　　　★★★★
lighttpd-fcgi　　　　★★　　★★★★★　　★★★★★
(上图来自应用Rails进行敏捷Web开发　P22 各种部署选择比较)

虽然没有提及IIS，不过肯定也有模块可以在上面跑。

优化考虑：
lighttpd:占用，轻量级。建议只在上面提供图片，JavaScript，样式表，中等规模的文件下载以及其他静态的页面。但不建议存放至关重要的数据，因为lighttpd据说存在一些严重的稳定性问题，在进行大量文件传输时候也有问题。

Ruby On Rails 顺利移植的提示

《Ruby on Rails 移植指南》一文中作者：Matt Kern提到关于数据库外键对于顺利移植的观点。我觉得相当认同。

虽然许多开发人员喜欢在数据库中充分利用各种约束，但我发现在数据库中取消大部分限制更简单、更清洁。我认为约束是应用程序业务逻辑的一部分，并且发现当它们位于应用程序代码中和数据库外时更易于跟踪。以外键为例；尽管没有将外键添加到移植的内置方法，但有插件和其他帮助可供使用。然而，我显然有点茫然，因为我认为它们并不可取。向移植添加外键会降低数据库独立性，而且在尝试修复出错数据时会导致问题发生。可以依赖 Rails 过滤器和验证，从而避免与添加外键相关的问题。许多开发人员（包括我自己在内）都希望能够在 SQLite3 等轻型数据库上进行开发，在 Oracle 等大型工具上进行部署和生产，移植中的外键在 SQLite 上将不能正常使用。保持灵活。

尝试使每个移植类成为一个单独的任务或特性。选择最适合的工作并坚持不懈。我的经验是如果文件/类名过长，不能描述即将进行的更改，则应将其分类成 单独的移植。您应该能够根据文件名识别更改，而无需深究程序代码本身。记住，这样做的目的是使开发更高效、更愉快。我甚至可以告诉您一个小秘密： ActiveRecord 和移植也可以在 Rails 框架外使用。（当然上，这实际上并不是一个秘密，但了解这一点还是有好处的！）

最后，测试，测试，再测试。在投入生产之前，确保移植是可靠的。运行移植时，任务的完成顺序很重要，因此测试是重中之重。例如，如果您视图在删的数 据之前更改包含该数据的列，移植将失败。我认为，最严重的错误莫过于将未经过全面测试的移植投入生产。移植很强大，但果您不够细心，它们会损坏生产数据 库。当然，为了提高开发流程效率和舒适度，如何明智地使用移植还需要长期的努力。

Ruby on Rails 移植(Migration)指南

Ruby on Rails 移植指南

http://www.oracle.com/technology/global/cn/pub/articles/kern-rails-migrations.html

使用 ActiveScaffold 增强 Ruby on Rails 的功能

http://www.ibm.com/developerworks/cn/linux/l-activescaffold/

has_many :through详解

原E文地址：http://blog.hasmanythrough.com/2006/04/20/many-to-many-dance-off

我已注意到使用 Rails 关联在创建多对多关系的两种方式上有些混乱。出现混乱是可以理解的，因为 has_many :through 还有些新，写它的文章并不多。

Has_and_belongs_to_many 出现的较早，确定的角色与资料超出了你为什么使用多对多关系的假设。事实上，许多人似乎并没有抓住本质上的区别。

就像我们从观看经典影片所学到的，告诉我们两个预期选择之间的区别最好方式是它们的舞蹈。你得观察每个人的表演。那么我们必须在两者之间选择哪个演员呢？

一、连接表：简单的关联

表：

create_table "dancers_movies", :id => false do |t|

t.column "dancer_id", :integer, :null => false

t.column "movie_id", :integer, :null => false

end

模型：

class Dancer < null =""> false

t.column "movie_id", :integer, :null => false

t.column "character_name", :string

t.column "dance_numbers", :integer

end

模型：

class Appearance < dependent =""> true

has_many :movies, :through => :appearances

end

class Movie < dependent =""> true

has_many :dancers, :through => :appearances

end

has_many :through 关联对这个简单例子来说很容易设定的，但是当使用其它特征如 polymorphism 时要有些技巧。用于连接模型的表有个主键并包含了类似其它模型的属性。

三、Checking out the moves

下面是对两种操作基本特征的比较

-----------------------------------------------------------------------------------

关联 has_and_belongs_to_many has_many :through

----------------------------------------------------------------------------------

AKA habtm 关联 遍历关联

结构： 连接表(Join Table) 连接模型(Join Model)

主键： 无 有

富关联 否 是

代理集合 是 否

Distinct 选择 是 是

自引用 是 是

早期加载 是 是

多态性 否 是

多向连接 否 是

------------------------------------------------------------------------------------------

该表格内包含了很多东西，现在我们分别看一下：

(1)、结构：

has_and_belongs_to_many 使用了简单的连接表，表的每一行记录只有两个外键。没有为连接表使用模型类的连接记录从不会被直接访问。

has_many :through 更新连接表为一个完整的模型。它使用一个模型类来表现表内的条目。

(2)、主键：

连接表没有主键。我听说一些人，如从外键对创建一个主键，但 Rails 从不为任何东西使用主键。我不能肯定你为什么要得到创建的主键，虽然它可能依据你数据库给你一些性能上的好处。 (我不是一个 DBA ，所以对于主键不想说得太多。)

连接模型有键，就像其它模型。这意味着你可以直接地访问及管理记录。

(3)富关联：

在 Rails 1.1 以前，你使用 push_with_attributes 来存储额外的属性到你的 habtm 连接表内。这样做会带来很多问题，包括随后不能更新属性。Push_with_attributes 现在不再使用了。如果你希望一个带有额外属性的富关联的话，使用连接模型。

(4)、代理集合：

使用 habtm 的一个好处是，关联是个代理集合。这意味着你可以使用关联的 << 方法在连接表内创建条目，就像 has_many 关联。因为连接模型记录有这些额外属性，所以用同样方式来自动创建连接表条目会更复杂。所以你必须手工创建连接模型条目。(更完整的解释，可参阅我的 Why aren't join models proxy collections? 文章。) (5)、Distinct 选择： 有时候，连接表(或模型)在同样的记录之间可能有多个引用。例如，一个人可能是一本书的作者及插图绘制者。如果你有多个引用，数据库会返回给你所有与你查 询相关多条记录。选项 :uniq 告诉关联过滤重复的对象，以便你只得到每个记录的一条显示。这类似于在 SQL 中使用 DISTINCT 关键字，但这是在 Ruby 内而不是数据库内移除重复发生的记录。这篇文章原只由 habtm 支持的 :uniq 才能查到，但现在通过 through 关联也可以查到。 (6)、自引用： Habtm 与 through 关联都可是自引用的。Users 的朋友用户就是一个自引用关系的例子。你可以通过在关联上使用带有 :foreign_key 与 :association_foreign_key 选项的 habtm 来完成。同样也可以使用 through 关联，因为它的做法不太明显，所以稍后我会写出如何处理它。 (7)、早期加载 Habtm 与 through 关联都通过 :include 选项来支持被关联对象的早期加载。 (8)、多态性： 连接模型与 through 关联可以用 polymorphic 模型类型工作。 (9)、多向连接 一个 habtm 关联只可以连接两个模型。但有时候你需要表现多个模型的关联。例如登记的可能是一位飞行家，一个乘客，及一个座位的分配。使用 through 关联，你可以创建一个连接模型，它连接你需要的多个模型。技巧部分是如何构建可方便地得到被关联对象的查询。 四、And the winner is... has_and_belongs_to_many 的使用范围狭小。但 has_many :through 则很广泛。 Seriously, there's no way to pick a winner here. Like any engineering decision, choosing a join table or a join model is a matter of picking the right tool for the job (or the right dancer for the part). Now that you've seen our players go head to head, you can make a better choice about who should get that part. 五、回帖部分： 1、David on 2006年4月21日 关于 distinct 选择 ---- 我认为你可以附加 :select 'DISTINCT *' 给关联，类似于： has_many foos, :through => bars, :select 'DISTINCT *'

案例:rapidreportig.com压力测试

Rapid Reporting 将他们的“身份及收入验证 引擎”运行在Rails系统上。美国1000强的抵押担保商有80%都使用这套引擎，每月处理2百万次抵押申请交易。

一开始，，Rapid Reporting希望检验Rails是否能够胜任，因此他们从10台集群机器向一个应用程序进行压力测试，每秒3千次请求。真是的应用程序大概需要每秒300次请求，并执行一系列的业务逻辑。因此，处理抵押业务必须遵循GLBA，因此很多地方都需要检查授权许可、生成查账索引。

应用程序使用PostgreSQL作为数据库，lighttpd作为web服务器，每台应用服务器运行大约10个FastCG进程，在一台虚拟服务器上用IP隧道技术实现负载均衡。使用这种部署方式，就可以随时增减FastCGI进程，而不必重启web server。由此又可以实现进程管理的自动化：用一个守护进程监视负载情况，当负载达到峰值时分配更多的FastCGI进程。