Custom Rails Environments

Sometimes you need to create another environment for your rails application aside from development, test, production. In this example we will create a “stage” environment. Here is how you do it. First create the entry in your config/database.yml file:

# Stage database configuration
stage:
  adapter: sqlite3
  database: db/stage.sqlite3
  timeout: 5000

Next create a file called stage.rb and place it into config/environments. I usually just copy my development.rb file and then change the values as needed: Finally, In your config/environment.rb file, change the ENV[‘RAILS_ENV’] to:

ENV['RAILS_ENV'] ||= 'stage'

Now when you boot up your server or console, just specify the “stage” environment.

session[:current_user] = @user => BAD!

I’m sure most of you already would know this, or use restful authentication that handles it for you. However, if you have some custom setup where you are loading a user object, and then storing it in session, slap to you! Basically what I am talking about is doing this in your login method:

session[:current_user] = @user

Instead you should do:

session[:current_user] = @user.id

And then in your application controller, setup a before filter like so:

def set_current_user
  @current_user = User.find(session[:current_user])
end

One main reason not to do that would be if you had to update some user information. If you had it stored in session, then the user would have to log out and log back in for the changes to take effect. This is of course a basic rough draft, but you get the idea.

Rails Security – SQL Injection – Sanitize User Input!

Even though rails makes every effort to help with security in your apps, you should still be proactive about it. Don’t just assume that your data will be safe no matter how you code. Here is a prime example. You have a login form and you process the request like this:

user = User.find(:first, :conditions=>["login = '#{params[:login]}'"])

You just essentially told every hacker to kill your data by doing something like “‘; delete from users;–“, or even worse a database drop. The appropriate way would be like this:

user = User.find(:first, :conditions=>['login = ?', params[:login]])

Other things you want to make sure you do is to sanitize your views as well:

<%= h @model.value %>

Assume the worse and check all your user input to make sure they can’t do anything you don’t want them to and you will have a happy APP!

Simple & Clean Rails Date/Time Format

Here is a quick, clean and easy way to get use from strftime on your date/time fields. Create a file called date_format.rb in the config/initializers directory and add the following code:

ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.merge!(
  :datetime_military => '%Y-%m-%d %H:%M',
  :datetime          => '%Y-%m-%d %I:%M%P',
  :time              => '%I:%M%P',
  :time_military     => '%H:%M%P',
  :datetime_short    => '%m/%d %I:%M'
)

Then in your views, you can do the following:

@object.time_field.to_s(:datetime)     # Or any other format you created

Rails TypeError (can’t dump File)

For a while, I kept getting exceptions from my app in the form of "TypeError (can't dump File):". I finally found out that this was caused when I was using active_record_store with something like file_column, attachment_fu, or paperclip. Basically whenever you’re storing a file in session, that was too large for the session, you would experience this issue. Here is how to get around it: Say you have a model like so (This is using file_column):

class Model < ActiveRecord::Base
  file_column :filename
end

Then in your controller you would want to add a line before you redirect off to clear that session:

class Controller < ApplicationController
  def create
    @model = Model.find(params[:model])
    @model.save!
  
    params[:model][:filename] = nil rescue nil # Reset value here
  
    redirect_to models_path(@model)
  end
end

As you can see, I am resetting the filename value on the model. Now it shouldn’t complain that it can’t dump the file. Happy RAILSING!

Rails Unit Test multi-array params

While writing some tests the other day, I came across a little bit of a stump. I have an action that required the use of a multi-dimensional param such as:

param[:user][:name]

This is exactly what I was doing, but you get the picture. I could have easily changed it to a single array, but that not the point. The solution in this example, would be to nest your hash in the test such as:

def test_should_do_something
  post :create, :some_object=>{
    :name=>'Bob'
  }, :user=>{ :name=>'Something' }
end

Full message for error_messages_for

I found this somewhere while looking around for the easiest way to provide my own full message for the rails error_messages_for output. Basically what we are going to do here is provide a humanized string for a variable of the model, and when the error message is printed out, it will display that message. This give more control instead of just having “Email is required.”

class Person < ActiveRecord::Base

  HUMANIZED_ATTRIBUTES = {
    :name => "Please provide a name for this person.",
    :email => "You must specify an email address."
  }

  def self.human_attribute_name(attr)
    HUMANIZED_ATTRIBUTES[attr.to_sym] || super
  end

  validates_presence_of :name,  :message=>''
  validates_presence_of :email, :message=>''

end

Override default find conditions for model

Here is a little trick I use when I want to override a find method for a model, instead of adding the conditions option to my association. While I don’t think you should avoid using the conditions options in your associations, this will provide an alternative:

class ModelName < ActiveRecord::Base
  def self.find(*args)
    with_scope(:find=>{ :conditions=>LIMIT_CONDITION }) do
      super(*args)
    end
  end
end

Basically what is happening, is that you are overriding the default find function for a model, and wrapping its own find method with a with_scope call. So now every time you call Model.find(:all) or whatever options you want, it will execute it under that scope, with the conditions you specify.

Application Error – Rails application failed to start properly

If you’re like me at all, you have run into this issue many times trying to upload your favorite Rails app to your webhost. This can be a very annoying and painful process if you do not understand what is going on exactly so I am going to outline a few tips to follow when attempting to release your new app, and if those tips do not work, I have my final tip that is actually quite useful. Here is my checklist:

  • Uncomment ENV[‘RAILS_ENV’] ||= ‘production’ in environment.rb
  • log and tmp directories have CHMOD 777 access.
  • ALL dispatch files in the public directory are CHMOD 755 at least.
  • Make sure the RAILS_GEM_VERSION is set to something installed on the server.
  • If you have unpacked any custom gems, make sure your app is loading them properly.
  • Make sure any gems you are using are installed on the server.
  • Make sure database.yml file is pointed to correct database.

These usually get the job done, and if you still have issues, feel free to comment here and I’ll try and help. One thing I have done in that past that helps out really well is to use a “skeleton” app. Basically what I do is the following:

  1. Run rails <appname>_skeleton where your actual app is going to run. This is the app that your domain name will actually use.
  2. Upload the app your working on to some directory on your host.
  3. The key part is here. You are going to symbolically link folders from inside your skeleton app and the folders you would like to do are:
  • app
  • config (Sometimes I link everything inside except the database.yml file and manage it only on the host)
  • db
  • lib
  • test
  • vendor
  • Everything inside public folder except the dispatch files.

This has come in very useful for me as I do not have to worry about permissions on the dispatch files everything I svn up the public directory and my logs are contained by them self. I can also go into my actual app(not the skeleton one) and just run an svn up. You may have to work with the links a little bit to get it working. If anyone has any comments on this idea or improvements, I would love to hear them.

Rails error: syntax error, unexpected tINTEGER Object::1

When trying to do a model.find(), I ran into the error, 'syntax error, unexpected tINTEGER Object::1'. If you have a table that uses a magic or reserved name, such as type, you will get this error. This error was a pain in the ass, but I figured out that you can get by it:

class SomeModel < ActiveRecord::Base
  self.inheritance_column = ''
end

The inheritance_column override is the key, basically giving it a different value to use. Hope this helps!