Rails - Nov 2005 - Subdomains as account keys

Hi,

For a multi-user, multi-account environment it''s logical to have an
accounts
table+class, and the information on using subdomains as account keys proved 
helpful:
http://wiki.rubyonrails.com/rails/pages/HowToUseSubdomainsAsAccountKeys

I''m just wondering though. in observance of the DRY principle, is there
a way
to filter all queries on account at the model level? I''m not about to
go
replacing all my existing Someclass.find(id) calls with 
Account.find(id).Someclass.find(id) scattered across many controllers, unless 
that''s the way it''s done?

-- 
Mark Beattie
Easy Schedule Management
http://easy-online-schedule.com

On 4.11.2005, at 10.20, Mark Beattie wrote:
> Hi,
>
> For a multi-user, multi-account environment it''s logical to have
an
> accounts
> table+class, and the information on using subdomains as account  
> keys proved
> helpful:
> http://wiki.rubyonrails.com/rails/pages/ 
> HowToUseSubdomainsAsAccountKeys
>
> I''m just wondering though. in observance of the DRY principle, is
> there a way
> to filter all queries on account at the model level? I''m not about
> to go
> replacing all my existing Someclass.find(id) calls with
> Account.find(id).Someclass.find(id) scattered across many  
> controllers, unless
> that''s the way it''s done?
Mark,

This has been discussed extensively lately on this list. The short  
answer: use @current_account.pages.find(params[:id]) whenever  
possible (instead of Page.find(params[:id])). It provides you with  
another layer of security since there''s no way that a user could see  
a page that doesn''t belong to his account by just editing the id url  
parameter.

Talking about DRY, you can set the current account with a  
before_filter that checks the session hash and creates the object  
accordingly. That way you will have the account object at your  
disposal in every action.

Example

class ApplicationController ...
	before_filter :create_account

	private

	def create_account
		@current_account = Account.find(session[:account_id])
	end
end

You will of course need some kind of authentication mechanism that  
sets the session[:account_id] variable.

//jarkko
>
> -- 
> Mark Beattie
> Easy Schedule Management
> http://easy-online-schedule.com
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
--
Jarkko Laine
http://jlaine.net
http://odesign.fi



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Thanks Jarkko, much appreciated.

I like your point about the added security of using 
@current_account.pages.find() instead of Page.find(). It''ll make me
feel
better about having to go through all my controllers and add it in.

I''m just glad I came across it in the early stages of DB planning
before
having scaffolded too much together. It''s nice to be able to use the
model to
set the current account, but it would be nicer if there was a means of 
telling AR which path each class takes through the DB schema to the accounts 
table and have it do the filtering automatically.

Maybe something like:

class SomeClass < ActiveRecord::Base
  belongs_to :another_class
  account_hierarchy  :another_class, :another_class_parent, :etc
end

and it could just use the associations and joins defined in each model listed 
in the hierarchy. With a sprinkle of magic dust.

-- 

Mark Beattie
Easy Schedule Management
http://easy-online-schedule.com