爲什麼在rails 3.2中'active_record.mass_assignment_sanitizer =：strict'？

Question

默認情況下，rails 3.2在config/environments/development.rb中設置active_record.mass_assignment_sanitizer = :strict。 （見軌道廣播節目http://railscasts.com/episodes/318-upgrading-to-rails-3-2）。那就是：

# Raise exception on mass assignment protection for Active Record models 
config.active_record.mass_assignment_sanitizer = :strict 

這使得開發和力mass assignment容易出錯列出每一個屬性爲attr_accessible。默認情況下，在rails 3.2（還沒有檢查它是否爲rails 4）時做這件事的理由是什麼？

Answer 1

Baldrick提供的鏈接似乎已經消失。但我最近讀到一篇博客文章，讓Rails中的質量分配安全問題的演變非常有益的背景：http://net.tutsplus.com/tutorials/ruby/mass-assignment-rails-and-you/

我沒有在這個問題上的專家，但這裏是我的理解：在Rails的錯誤配置質量分配可能會導致真正的，非常大的安全問題，現在它們已經普及化，這一切都變得更加危險。 Rails 4試圖通過要求你明確地列出控制器中可以批量分配的字段來安全地修補最大的威脅，這些安全問題很容易讓你看到和處理。但是Rails 3中批量分配的處理更加多變，並且在很多情況下，如果提交的參數不在attr_accessible白名單中（或者在黑名單上的是），那麼Rails會簡單地忽略該參數，而沒有讓開發人員知道任何事情都發生了錯誤。

這是一個問題。如果我正在編寫一個需要高安全性（或者現在，任何級別的安全性）的應用程序，如果我已經寫了一個測試來確保某些參數被拒絕，我想知道他們被拒絕。我寧願找出Rails早日做什麼，以便我可以調整我的代碼並相應地規劃未來的網站部分。所以，mass_assignment_sanitizen = :strict設置會使這種更多的聲音行爲成爲默認行爲。

你說這個設置使批量分配行爲在開發中更加「容易出錯」，就好像這是一個問題。我認爲你會想要你的Rails應用程序在開發和測試階段，儘可能容易出錯並儘可能發聲，這樣你就可以更快地瞭解代碼中更多的潛在問題。所以我很欣賞mass_assignment_sanitizer默認值。

對我們倆來說幸運的是，Rails 4通過堅持嚴格的立場來簡化這個問題。嚴格的質量分配參數清理以及其容易出錯的聲音已成爲控制器的默認功能（因爲此問題從未真正屬於模型中的第一位），併爲您提供友好的專用功能可以定義您需要的任何替代行爲。