How do you implement lazy token authentication for non-registered users in Rails?

Question

UPDATE

I have further clarified my question, listed at the end of this post.

Problem Summary:

I am trying to implement lazy (aka soft sign-up) registration in Devise via an emailed URL which includes token authentication. On my site, a User has_many :payments, and a Payment belongs_to :user. When a User creates a new Payment, it includes the attribute :email which represents a new non-registered user (which I'll call "Guest"). I use ActionMailer to send an email to this new Guest.

In this email that is sent, I would like to include a URL with token authentication (e.g. http://localhost/index?auth_token=TOKENVALUE), so that the Guest can see and edit views that require authentication and are specifically customized to them (based on their :email). The Guest should also have the ability to register as a User - since I already have their email address, they would just need to provide a password.

My Progress So Far:

• I have implemented the ability for someone to register for the site using Devise and created the associated views, model and controller to make changes to my Payment model
• I have setup ActionMailer and am using it to send emails, but have not yet setup token-authentication as I'm not sure how to do so given my use case above

Related Resources:

• https://github.com/plataformatec/devise/wiki/How-To:-Simple-Token-Authentication-Example
• http://zyphdesignco.com/blog/simple-auth-token-example-with-devise
• Multiple user models with Ruby On Rails and devise to have separate registration routes but one common login route
• how to create a guest user in Rails 3 + Devise
• https://github.com/plataformatec/devise/wiki/How-To:-Create-a-guest-user
• http://blog.bignerdranch.com/1679-lazy-user-registration-for-rails-apps/
• http://railscasts.com/episodes/393-guest-user-record?view=asciicast
• https://github.com/plataformatec/devise/wiki/How-To:-Manage-users-through-a-CRUD-interface
• Rails 3 - Devise Gem - How to Manage Users through CRUD interface
• http://danielboggs.com/articles/rails-authentication-and-user-management-via-crud/

/app/models/payment.rb

class Payment < ActiveRecord::Base
  attr_accessible :amount, :description, :email, :frequency, :paid, :user_id
  belongs_to :user

  validates :email, :presence => true, :format => { :with => /.+@.+\..+/i }
  validates :amount, :presence => true
  validates :description, :presence => true
end

/app/models/user.rb

class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable, :confirmable

  # I will also need to add ":token_authenticatable"

  attr_accessible :email, :password, :password_confirmation, :remember_me
  has_many :payments
end

Questions:

1. How can I keep my User table in sync with new Payments that are created, such that any new :email created in the Payment table automatically are added in the User table as an :email?
2. Following from question 1, the new User created should include a token but not include a password, since the User has not yet registered for the site. Should I create the new User with a blank password, randomly generated string, or other? In either case, I think they would need to come to the registration page from their token-authenticated URL to prevent others from registering under their email username (e.g. lazy registration)
3. Following from question 2, I think that I will need to distinguish between Guests and normal users, as some of the views will change depending on user type. Is there a preferred method other than adding a column that would have a 0 or 1 to delineate between the two user types?

My preference if possible is to use Devise since I am using many of the features included. I'm new to RoR and appreciate any advice you can provide!

EDIT: Here is the code I used to address question #1 above, in my payments controller, in case helpful to someone else

def create
    @payment = current_user.payments.build(params[:payment])

    #Here is the code I added to keep User :email in sync with Payment :email, without token authentication implemented yet
    unless User.find_by_email(params[:payment][:email].downcase)  
      u = User.new({:email => params[:payment][:email].downcase, :password => nil, :password_confirmation => nil })
      u.skip_confirmation!
      u.save(:validate => false)  #skip validation
    end

    respond_to do |format|
      if @payment.save
        format.html { redirect_to payments_url, :flash => { notice: 'Payment was successfully created.' } }
        format.json { render json: @payment, status: :created, location: @payment }
      else
        format.html { render action: "new" }
        format.json { render json: @payment.errors, status: :unprocessable_entity }
      end
    end
  end

Answer 1

Frameworks like Devise are great when you know how to use them well and what you want to do fits within what the framework was designed to do. When you start trying to "bend" them to do things they weren't designed to do, though, perhaps trying to monkey-patch them without fully understanding how they work internally, in my experience, you just make a mess. I've been there. Often you are reduced to just "hacking until it works"... which really means "hacking until it appears to work, aside from a dozen subtle bugs which only show up later".

In a case like this, I would be inclined to just "roll my own" login and authentication code, perhaps looking at the Devise source code for ideas.

(In fact, I did just that today on a new Rails app... it took a couple hours of hours, checking the Devise source for ideas now and again, to write the 200 lines of code my project actually needed. Devise itself, in comparison, has about 2500 lines.)

You asked for ideas on "overall strategy and structure" of the code. If you decide to implement your own custom login/authentication code, it will probably go something like this:

1. Store some information in the session hash to identify if the user is logged in, and as which Guest/User. Make sure your sessions are stored in the DB, not in cookies.
2. Add some methods to ApplicationController (or a Module mixed in to ApplicationController) to encapsulate access to this login information.
3. Put a before_filter on all pages which require login, which redirects if the user is not logged in.
4. Add a controller which authenticates users by password OR token, and allows them to log in/out.

5. For password storage/authentication, use the bcrypt-ruby gem. On your User model, you'll need a password_hash string field and probably some methods like:

   require 'bcrypt'
   def password
     # BCrypt handles generation and storage of salts
     @password ||= ::BCrypt::Password.new(password_hash)
   end
   def password=(password)
     @password = ::BCrypt::Password.create(password)
     self.password_hash = @password
   end
   def authenticate_by_password(password)
     self.password == password
   end
   

6. For token-based authentication, add a login_token string field to your User model (or Guest or whatever it is...). Make it a unique field. You can generate the unique tokens using something like this (borrowed from Devise and modified a little):

   require 'securerandom'
   def generate_login_token
     loop do
       token = SecureRandom.base64(15).tr('+/=lIO0', 'pqrsxyz')
       unless User.where(:login_token => token).exists?
         self.login_token = token
         self.save!
         return
       end
     end
   end
   

7. Then when a user hits your login action with params[:token] set, just do something like:

   if user = User.find_by_login_token(params[:token])
     # if the token is supposed to be "one time only", null out the attribute
     # log user in
   else
     # login token was invalid
   end
   

Make sure you put a DB index on the login_token field.

Is there anything else?