rails Archives - Richard Hart

All posts tagged “rails”

April 30, 2011

Devise Omniauth Dynamic Providers

My current project www.viewshound.com requires different users to have different scopes for their Facebook authentication. Warden supports dynamic providers out of the box. To get it working with Devise was pretty easy, just a couple of minor changes were needed especially to support Facebook.

First up was creating the new route. As I’m using a controller called Omniauth and not Session, the :to attribute is different. The other thing to note is I’m matching /users/auth/facebook/setup, not /auth/facebook/setup like in the Warden documentation.

routes.rb

devise_for :users, 
:controllers => { :omniauth_callbacks => "omniauth" }, 
:skip => [:sessions] do
match '/users/auth/facebook/setup', :to => 'omniauth#setup'
end

devise_for :users,

:controllers => { :omniauth_callbacks => "omniauth" },

:skip => [:sessions] do

match '/users/auth/facebook/setup', :to => 'omniauth#setup'

end

Next we create the new setup action for Warden to call. The docs use consumer_key and consumer_secret, but facebook expects client_id and client_secret, so be sure to use those instead. This is where I make changes to the scope based on the current user if they are signed in or not. So a user can re-authenticate with Facebook to get more permissions for their account if they wish.

omniauth_controller.rb

class OmniauthController < Devise::OmniauthCallbacksController
def setup
request.env['omniauth.strategy'].client_id = 
{your_facebook_id_here}
request.env['omniauth.strategy'].client_secret = 
{your_facebook_secret_here}
request.env['omniauth.strategy'].options = 
{:scope => your_facebook_scope_here}
render :text => "Setup complete.", :status => 404
end
end

class OmniauthController < Devise::OmniauthCallbacksController

def setup

request.env['omniauth.strategy'].client_id =

{your_facebook_id_here}

request.env['omniauth.strategy'].client_secret =

{your_facebook_secret_here}

request.env['omniauth.strategy'].options =

{:scope => your_facebook_scope_here}

render :text => "Setup complete.", :status => 404

end

Finally change the devise.rb initializer to support the new setup.

devise.rb

config.omniauth :facebook, nil, nil, :setup => true

config.omniauth :facebook, nil, nil, :setup => true

Restart your application and you should be good to go.

January 18, 2010

Thoughtbot Clearance & mongomapper

Having a play with mongomapper and wanted to get Clearance working with it. Seemed to just be a simple case of doing the following in my user model.

def self.attr_accessible(*args)end
include Clearance::User

1 2	def self.attr_accessible(*args)end include Clearance::User

My full user model ended up looking like this:

class User
include MongoMapper::Document
def self.attr_accessible(*args)end
include Clearance::User
key :email, String
key :encrypted_password, String
key :salt, String
key :confirmation_token, String
key :remember_token, String
key :firstname, String
key :email_confirmed, Boolean
key :lastname, String
timestamps!
end

class User

include MongoMapper::Document

def self.attr_accessible(*args)end

include Clearance::User

key :email, String

key :encrypted_password, String

key :salt, String

key :confirmation_token, String

key :remember_token, String

key :firstname, String

key :email_confirmed, Boolean

key :lastname, String

timestamps!

end

Perhaps if I have time, I will look into adding attr_accessible support to mongomapper myself.

Update 13/03/2010: I believe the dependency on attr_accessible in clearance has since been removed. So this small hack is most probably defunct.

October 25, 2009

Law of Demeter and the delegate method

The Law of Demeter, or Principle of Least Knowledge is a fairly simple design pattern, which, simply put means that an object should only talk to it’s immediate “friends”

The law states that a method M of and object O may only invoke the methods of the following kind:

1. a method on O itself
2. any parameters passed to M
3. any objects instantiated within M
4. any direct components of O

The classic example coined by David Bock used a Paperboy (one object) delivering a paper, then extracting money from a Customer’s (another object) Wallet (and another):

class Paperboy
def get_payment(customer)
self.money += customer.wallet.take_out(10)
end
end

class Paperboy

def get_payment(customer)

self.money += customer.wallet.take_out(10)

end

In the “real world” the Paperboy would ask the customer for the money who would then take it out for them, rather then the Paperboy reaching into the customer’s back pocket and getting it for themself.

Really we want something as follows:

class Paperboy
def get_payment(customer)
self.money += customer.get_payment(10)
end
end
class Customer
def get_payment(amount)
wallet.take_out(10)
end
end

class Paperboy

def get_payment(customer)

self.money += customer.get_payment(10)

end

class Customer

def get_payment(amount)

wallet.take_out(10)

end

This may all seem trivial and a waste of time, but what happens if some Customers want to pay by cheque? Those decisions should have an impact on the Paperboy, otherwise we end up with:

class Paperboy
def get_payment(customer)
if customer.pay_by_cash?
self.money += customer.wallet.take_out(10)
elsif customer.pay_by_cheque?
self.money += customer.cheque_book.write_cheque(10)
end
end
end

class Paperboy

def get_payment(customer)

if customer.pay_by_cash?

self.money += customer.wallet.take_out(10)

elsif customer.pay_by_cheque?

self.money += customer.cheque_book.write_cheque(10)

end

Where as it makes more sense for the change to be contained within the Customer:

class Paperboy
def get_payment(customer)
self.money += customer.get_payment(10)
end
end
class Customer
def get_payment(amount)
if pay_by_cash?
wallet.take_out(10)
elsif pay_by_cheque?
cheque_book.write_cheque(10)
end
end
end

class Paperboy

def get_payment(customer)

self.money += customer.get_payment(10)

end

class Customer

def get_payment(amount)

if pay_by_cash?

wallet.take_out(10)

elsif pay_by_cheque?

cheque_book.write_cheque(10)

end

So what does this have to do with Rails and the delegate method? The delegate method adds a quick and simple way of following the Law of Demeter without having to do very much at all.

class Order
belongs_to :customer
end
class Customer
has_many :orders
has_one :credit_card
has_one :bank_account
def payment_method
if pay_by_card?
credit_card
elsif pay_by_account?
bank_account
end
end
end
class CreditCard
belongs_to :customer
end
class BankAccount
belongs_to :customer
end

class Order

belongs_to :customer

end

class Customer

has_many :orders

has_one :credit_card

has_one :bank_account

def payment_method

if pay_by_card?

credit_card

elsif pay_by_account?

bank_account

end

class CreditCard

belongs_to :customer

end

class BankAccount

belongs_to :customer

end

This setup means to get an Order’s payment we would have to say:

@order.customer.payment_method.withdraw(amount)

1	@order.customer.payment_method.withdraw(amount)

But if we simply change our objects as such:

class Order
belongs_to :customer
delegate :withdraw_payment, :to => :customer
end
class Customer
has_many :orders
has_one :credit_card
has_one :bank_account
def withdraw_payment(amount)
if pay_by_card?
credit_card.withdraw(amount)
elsif pay_by_account?
bank_account.withdraw(amount)
end
end
end

class Order

belongs_to :customer

delegate :withdraw_payment, :to => :customer

end

class Customer

has_many :orders

has_one :credit_card

has_one :bank_account

def withdraw_payment(amount)

if pay_by_card?

credit_card.withdraw(amount)

elsif pay_by_account?

bank_account.withdraw(amount)

end

Now all we have to say is:

@order.withdraw_payment(amount)

1	@order.withdraw_payment(amount)

So at any time, the details of how a payment is to be decided can be contained with the Customer. This is of course a simplistic example, but hopefully explains how you chould be using this handy feature.

September 15, 2009

Vlad 2.0 Not Finding Tasks in deploy.rb

When I restalled all my gems on Snow Leopard, vlad refused to find any of the tasks I had defined in my deploy.rb. I thought this was a SL issue but turned out a week before it’s release Vlad had been updated to version 2 which used a new plugin system. Looking for vlad rake tasks returned an error:

>> rake -T vlad
Could not load vlad: no such file to load -- vlad/git

1 2	>> rake -T vlad Could not load vlad: no such file to load -- vlad/git

To solve the problem just required an install of the new vlad-git gem.

>> sudo gem install vlad-git

1	>> sudo gem install vlad-git

Now all my tasks were appearing properly. Vlad 2 always brought around a few changes in it’s deploy.rb and use. Here is my deploy.rb for reference:

set :application, "yourdomain"
set :domain, "yourdomain@yourdomain.com"
set :user, "yourdomain"
set :repository, "git@github.com:youraccount/yourdomain.git"
task :staging do
set :revision, "origin/staging"
set :deploy_to, "/opt/yourdomain.staging/"  
end   
task :production do
set :revision, "origin/master"
set :deploy_to, "/opt/yourdomain/"  
end
namespace :vlad do
desc "Pull from git, run migrations, then (re)start the app server"
task :migrate_deploy => &#91;:update, :migrate, :start_app]
desc "Pull from git then (re)start the app server"
task :deploy => &#91;:update, :start_app]
desc 'Restart Passenger'
remote_task :restart do
puts "Touching: #{deploy_to}current/tmp/restart.txt"
run "touch #{deploy_to}/current/tmp/restart.txt"
end
end

set :application, "yourdomain"

set :domain, "yourdomain@yourdomain.com"

set :user, "yourdomain"

set :repository, "git@github.com:youraccount/yourdomain.git"

task :staging do

set :revision, "origin/staging"

set :deploy_to, "/opt/yourdomain.staging/"

end

task :production do

set :revision, "origin/master"

set :deploy_to, "/opt/yourdomain/"

end

namespace :vlad do

desc "Pull from git, run migrations, then (re)start the app server"

task :migrate_deploy => [:update, :migrate, :start_app]

desc "Pull from git then (re)start the app server"

task :deploy => [:update, :start_app]

desc 'Restart Passenger'

remote_task :restart do

puts "Touching: #{deploy_to}current/tmp/restart.txt"

run "touch #{deploy_to}/current/tmp/restart.txt"

end

Now invoking Vlad for my staging environment works as such:

>> rake staging vlad:deploy

1	>> rake staging vlad:deploy

August 6, 2009

rake spec fixtures failing

For some reason my rspec fixtures were not loading into my development database when doing spec:db:fixtures:load. An extra parameter to db:fixtures:load is all that’s needed.

&gt;: rake spec:db:fixtures:load
rake aborted!
uninitialized constant Fixtures

>: rake spec:db:fixtures:load

rake aborted!

uninitialized constant Fixtures

Fixed by:

&gt;: rake db:fixtures:load FIXTURES_PATH=spec/fixtures

1	>: rake db:fixtures:load FIXTURES_PATH=spec/fixtures

February 15, 2009

RSpec + Autotest + Growl + Doom Guy

I spent this morning playing around with autotest, but was getting really flaky results with the Growl notifications. I tried about four different autotest configs, but none of them seemed to consistently worked. I remembered that the Growl notifications at Thursday’s Coding Dojo worked pretty well, so after some digging around I found the config on their github. After a tiny tweaking I was even able to get it to work with Przemysław Kowalczyk’s Doom Guy. I’ve packaged it all up and put it on Github. Enjoy.

doomguy-growl-autotest