Showing posts tagged rubyonrails

Beware respond_to format with redirects in shared systems before_filter - DoubleRenderError

If you use an authenticated_system on your Rails site, with global before_filters for things like requiring login to access pages, be careful of missing formats in the respond_to.  I just tracked down a bug on an app where we were getting DoubleRenderErrors because of unauthenticated request directly to a csv file.  We had a before_filter that was denying request and redirecting them to login, in different ways, depending on the format, but hadn’t thought to include csv.  In this case, it is wise to include a catch-all at the end using .any

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 



def anon_access_denied



  respond_to do |accepts|



    accepts.html do



      store_location



      redirect_to login_path



    end



    accepts.xml do



      headers[“Status”]           = “Unauthorized”



      headers[“WWW-Authenticate”] = %(Basic realm=”Web Password”)



      render :text => “Could’t authenticate you”, :status => ‘401 Unauthorized’



    end



    accepts.js do 


      render(:update) { |page| page.redirect_to login_path }



    end



  end



end


  		 


      
  Posted via web   from a timocracy of one | Comment »  
  

				

			
 
			
			
			
			
			
			
			 
		
 
		
		

			
			

				
			
 
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
				
				
Making config.gem in Rails 2.3.x allow you to install from a direct url or the local filesystem

				

					


If you are on Rails 2.3.x (pre-Bundler) and want to organize some of your shared functionality into gems, but they are for internal use only, you could set-up a private gem server and point the :source at this server.  And then you could deal with authentication, and then…
  
Or as a quick hack you could just allow for config.gem to reference the gemfile directly, which would then mean ‘rake gems:install’ would work, even if the gem were stored locally, or on a file-server, etc.  Also useful as you could then just point at a .gem file on github.
  

  

  
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
 		   




## require in config/environment.rb before init starts


#require ‘config/add_explicit_path_to_config_gem’


#Rails::Initializer.run do |config|


#config.gem ‘my_gem’, :version => ‘0.0.1’, :explicit_path => “#{RAILS_ROOT}/vendor/local_gemfiles/my_gem-0.0.1.gem” #or


#config.gem ‘my_gem’, :version => ‘0.0.1’, :explicit_path => “http://github.com/myname/myrepo/raw/master/mygem.gem” #or


 



module Rails



  class GemDependency



    def initialize_with_explicit_path(name, options = {})



      @explicit_path = options[:explicit_path]



      initialize_without_explicit_path(name, options = {})



    end



    alias_method_chain :initialize, :explicit_path



    


  private



  


    def install_command



      cmd = %w(install) « (@explicit_path || name)



      cmd « “—version” « %(“#{requirement.to_s}”) if requirement



      cmd « “—source”  « @source  if @source



      cmd



    end



  end



end


  		 


      
  Posted via web   from a timocracy of one | Comment »  
  

				

			
 
			
			
			
			
			
			
			 
		
 
		
		

			
			

				
			
 
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
				
				
“Object is not missing constant XXX” and “A copy of YYY has been removed from the module tree but is still active” when using Rails metal

				

					


If you have a Rails metals that has enough code to have its own subdirectories that live in your Rails load_paths you can get stuck in dependency hell. The combinations of autoloading, rails reloading on development, and running through the metal can intersect in nasty ways: on the first request you get “Object is not missing constant XXX” and subsequent requests kick off “A copy of YYY has been removed from the module tree but is still active.”
  
The easiest solution is to kill magic reloading for this metal’s code by adding the metal’s directories of code to the Rails load_once_paths and then using explicit require_dependency calls for any files that give you trouble. For example, I have a MadMetal that referenced a Mad which has a whole sub-directory structure of code that, for now, lives under lib/mad:
  
#config/environment.rb  config.load_once_paths += Dir["#{RAILS_ROOT}/lib/mad/**/"]    #app/metal/mad_metal.rb  require_dependency 'mad'  class MadMetal  def self.call(env)  if (env["PATH_INFO"] == '/the_path_to_my_metal')  Mad.call(env)  else  [404, {"Content-Type" => "text/html"}, ["Not Found"]]  end  end  end
  
And wallah, no more conflicts between development auto-reloading and metal.
  
Of course, now you need to restart the server if you change code in lib/mad. In this case it’s not a problem for me because the app is also a stand-alone rack app that I run with shotgun when I want development environment reloading.
      
  Posted via email   from a timocracy of one | Comment »  
  

				

			
 
			
			
			
			
			
			
			 
		
 
		
		

			
			

				
			
 
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
				
				
Setting RAILS_ENV on Dreamhost when running Passenger

				

					
It may depend on which server you are on, but mine has mod_env 
enabled, so it’s a simple matter of setting the ENV[‘RAILS_ROOT’] in 
an .htacess file 
 
SetEnv RAILS_ENV staging
      
  Posted via email   from a timocracy of one | Comment »  
  

				

			
 
			
			
			
			
			
			
			 
		
 
		
		

			
			

				
			
 
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
			
				
				
Avoiding some of the negative trade-offs in the template pattern with ruby’s dynamicism?

				

					
So my buddy Tammer’s recent post about the Gang of Four’s Template Pattern reminded me of some code I saw recently.  A start-up’s greenfield project had it’s authorization done in a pretty clean way using the template pattern.  Basically every object determined what could be done to it, something like this:






After continuing this approach to fully cover CRUD you make a straight-forward set of accessors that can be used to easily enforce permissions in the controller in a programmatic way (this project was using on of the inherited resourceful-controller plugins, so that was a big plus).  The developer who implemented this commented that the trade-off for this simplicity was having to look in each individual model file to figure out what a user can do overall.  I figured I liked everything about this scheme except that trade-off, and since ruby is so dynamic, why settle for almost.  Why not just reopen each class in the authorization file and add the methods.  You still get the simplicity and encapsulation of having the model able to determine it’s own permissions, based on it’s state and methods, and there is still one place to look to review/change the permissions for the whole project:






Thoughts?



  Posted via web   from a timocracy of one | Comment »