title: Rails: best practice to scope queries based on subdomain?
body: <p>I'm working on a Rails (currently 2.3.4) app that makes use of subdomains to isolate independent account sites. To be clear, what I mean is foo.mysite.com should show the foo account' content and bar.mysite.com should show bar's content.</p>
  
  <p>What's the best way to ensure that all model queries are scoped to the current subdomain?</p>
  
  <p>For example, one of my controllers looks something like:</p>
  
  <pre><code>@page = @global_organization.pages.find_by_id(params[:id])        
  </code></pre>
  
  <p>(Note <code>@global_organization</code> is set in the application_controller via subdomain-fu.)
  When what I would prefer is something like:</p>
  
  <pre><code>@page = Page.find_by_id(params[:id])
  </code></pre>
  
  <p>where the Page model finds are automatically scoped to the right organization. I've tried using the  default_scope directive like this: (in the Page model)</p>
  
  <pre><code>class Page &lt; ActiveRecord::Base
    default_scope :conditions =&gt; "organization_id = #{Thread.current[:organization]}"
    # yadda yadda
  end
  </code></pre>
  
  <p>(Again, just to note, the same application_controller sets Thread.current[:organization] to the organization's id for global access.) The problem with this approach is that the default scope gets set on the first request and never changes on subsequent requests to different subdomains.</p>
  
  <p>Three apparent solutions thus far:</p>
  
  <p>1 Use separate vhosts for each subdomain and just run different instances of the app per subdomain (using mod_rails). This approach isn't scalable for this app.</p>
  
  <p>2 Use the original controller approach above. Unfortunately there are quite a number of models in the app and many of the models are a few joins removed from the organization, so this notation quickly becomes cumbersome. What's worse is that this actively requires developers to remember and apply the limitation or risk a significant security problem.</p>
  
  <p>3 Use a before_filter to reset the default scope of the models on each request. Not sure about the performance hit here or how best to select which models to update per-reqeust.</p>
  
  <p>Thoughts? Any other solutions I'm missing? This would seem to be a common enough problem that there's gotta be a best practice. All input appreciated, thanks!</p>