Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Authorization::Reader::DSLFileNotFoundError #99

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants

This fixes what seems to be a 'load order' bug cause by Rails.root being unavailable.

The environment this was experienced in is Rails 3.0.3, Ruby 1.8.7, declarative_authorization 0.5.2

Since constants are declared at load time and not run time, this bug pops up even though at run time, we have a fully functional Rails.root

99% of the time however, it is a non-issue as it falls back to the relative path of 'config/authorization_rules.rb', which when you are inside your Rails.root, works just fine.

The bug happens when you run code that invokes declarative_authorization outside of Rails.root. Manually running integration tests inside your test folder for example or stand-alone scripts in a bin folder.

Considering AUTH_DSL_FILES is referenced only once in the entire project, moving it into the Reader::DSLReader's factory method call seemed like a somewhat sane idea.

Owner

stffn commented Apr 21, 2011

We need to be careful here. There are people using that constant to configure the location. Given that the constant occurs in the documentation, we should try to keep it.

As an alternative approach: What about not setting the constant by default, but use it instead of Rails.root if defined at that point?

While people may be using it, some thought needs to be put into whether or not the mechanism for this configuration option should remain a constant.

Your suggestion for the alternative approach does solve this issue, but still requires the use of a constant, which some would consider sloppy.

An even better approach would be to deprecate the constant in a future release, while introducing a method call to explicitly set the file path.

Owner

stffn commented Apr 23, 2011

Absolutely. I'm fully with you there. There also is a issue on a better configuration infrastructure, in which the file path setting could be integrated. This would be a good point to make a first step. Only, we should keep the constant as a deprecated way in there.

Owner

stffn commented Apr 23, 2011

I was referring to #44

Awesome, I'll play around with some ideas and if anything decent comes of it I'll send it your way.

Contributor

inkdeep commented Jun 29, 2011

I know probably a silly idea but what about walking up the directory tree looking for a config directory?

Dir.chdir('..') while !Dir.entries(Dir.pwd).include?('config')

Then the file path is correct for 'config/authorization_rules.rb'

I've hit this problem with name spaced controllers in functional tests.

I'm hitting this problem currently when deploying via Capistrano and Thin. I attempt to change the directory so that the file path fallback functions properly:

run "cd /var/wwwpath/to/app/current && bundle exec rails server thin -e qa -p 4002 --daemon"

However it still seems unable to find the file:

Error reading authorization rules file with path 'config/authorization_rules.rb'!  Please ensure it exists and that it is accessible.

Using Ruby 1.9.2, Rails 3.0.7, and Thin 1.2.11. I will continue to dig and let you know what I find, as it seems more likely to be an issue on my end.

It's an issue, so +1 from here.
The best way is probably to use the engine architecture to set the config path. And then just require the file without path. See Jose Valim's new book "Crafting Rails Applications"

Owner

stffn commented Aug 24, 2011

+1 for a patch on this, using the engine architecture. It needs to be backwards compatible to Rails 2.3, though.

Owner

stffn commented Apr 27, 2012

This is better tracked in #44

@stffn stffn closed this Apr 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment