Interesting Things
- If your HTTP header’s
HTTP_CLIENT_IPis not equal toHTTP_X_FORWARDED_IP, then rails 2.1 and above will consider it an IP spoofing attack and throw an exception! This is bad news for some traditional Apache->Mongrel setups. Solution is probably to change the apache HTTP headers, but we’re wondering exactly why this is a security problem for rails (and why they would break compatibility with the default apache setup from way back when)? - Be careful when using
validates_uniquess_ofwith:case_sensitive => trueAND a unique index at the database level. If your database is case insenitive, then rails will approve the uniqueness, but the database will fail the insert. Solution: be sure to use a collation type for the unique column that is case sensitive (such as binary in mysql). - Rails 2.1+
:includes are way better than pre-2.1, but they are less compatible with conditions. Hence, rails falls back on the old style. Here’s when it might legitimately fall back:
User.find(:all, :include => :profile, :conditions => "profiles.gender = 'M'")
Because we reference the included table profiles in the :conditions, rails has no choice but to construct one giant query to fetch Users and their profiles, rather than a separate query. Here’s a case when it guesses wrong:
User.find(:all, :include => :profile, :joins => "INNER JOIN comments ON comments.user_id = users.id", :conditions => "comments.approved = 1")
Because the conditions references a table that is not users, rails thinks it has to fall back to the old include style… but it’s wrong! Here’s how we tricked ActiveRecord into always using rails 2.1+ includes (note that we had to fix up a few queries that were referencing :inlcuded tables in :conditions to make this work):
module ActiveRecord::Associations::ClassMethods
private
def references_eager_loaded_tables?(options)
false
end
end

