Solution: Just as the Rails ActiveRecord class uses methods like belongs_to and validates_format_of to define model relationships and behaviors, create a new class method to express trimming behavior. There are a number of ways to do this; I will present one possibility that I have used in my own code. I created a file lib/trimmer.rb with the following contents:

module Trimmer
  # Make a class method available to define space-trimming behavior.
  def self.included base
    base.extend(ClassMethods)
  end

  module ClassMethods
    # Register a before-validation handler for the given fields to
    # trim leading and trailing spaces.
    def trimmed_fields *field_list
      before_validation do |model|
        field_list.each do |n|
          model[n] = model[n].strip if model[n].respond_to?('strip')
        end
      end
    end
  end
end

Then I write the following in my models:

require 'trimmer'
class MyModel < ActiveRecord::Base
  include Trimmer
  . . .
  trimmed_fields :first_name, :last_name, :email, :phone
  . . .
end

While this makes the behavior available to particular models explicitly, you may prefer to make this behavior available to all of your models implicitly. In that case, you can extend the ActiveRecord::Base class behavior by adding the following to config/environment.rb:

require 'trimmer'
class ActiveRecord::Base
  include Trimmer
end

If you do this, the trimmed_fields class method will be available to all of your models.

Context: You are developing a web application requiring user password authentication and using a password salt and hashing algorithm to store passwords.  You are reluctant to create a random nonce for your password reset token, since this needs to be stored in your database.  But this seems inefficient; in most cases, the user object doesn’t need to hold a nonce, but this seems like such a trivial problem to create an entirely new password reset nonce table to associate with the user object.

Solution: You can generate a unique password reset token by hashing the internal state of the user object, including the user’s password salt and password hash.  Because you are including the password salt and hash as part of the hash to produce the reset token, the reset token has the following properties:

1. It can be computed only by the server (the password salt and hashes should not be externalized),
2. It can be computed at any time by the server (it does not need to be stored in your database),
3. It is constant until the user changes their password (i.e., an attacker cannot cause it to be invalidated), and
4. It is guaranteed to change whenever the password is actually changed (since the user object’s internal state change from the password update will cause the reset token hash to change), so that an attacker who later discovers the token cannot exploit it.

If you desire to limit the viability of a password reset token to a certain period of time (e.g., 24 hours), you can include an expiration timestamp in the token and also as input to the hashing operation:

reset_token = timestamp + hash(timestamp + user.password_salt + user.password + ...)

By including the timestamp in the token, you provide an indication to your application when the token expires. By including the timestamp as input to the hash portion of the token, you ensure that it is not possible for an attacker to take a stale token and manufacture a valid token.