rescue_from ActionController::RoutingError II

OK ... so I'm not supposed to use it but ...

Why doesn't rescue_from ActionController::RoutingError work witht he code from http://www.rubyplus.org/episodes/20-Extended-RESTful-Authentication-Rails-2-App.html

class ApplicationController < ActionController::Base   helper :all # include all helpers, all the time

  # See ActionController::RequestForgeryProtection for details   # Uncomment the :secret if you're not using the cookie session store   protect_from_forgery # :secret => '34e000fc7cc2daeae150a89535f7f87d'

  # Be sure to include AuthenticationSystem in Application Controller   # instead   include AuthenticatedSystem

  #Shnelvar   debugger # This one gets hit   #neither rescue_from seems to work   rescue_from ActionController::RoutingError, :with => :route_not_found   # rescue_from ActionController::RoutingError, :with => :render_404

  protected

  def route_not_found     debugger #this one does not     render :text => 'What are you looking for ?', :status => :not_found   end   #Shnelvar end

end

Ralph Shnelvar wrote:

OK ... so I'm not supposed to use it but ...

Why doesn't rescue_from ActionController::RoutingError work witht he code from 7 Step Framework for Coding Skills Acquisition

Dude. You don't need to rescue from RoutingErrors -- Rails already handles that. You don't want to use restful_authentication -- Authlogic is better. Why are you so intent on figuring out how to do things that you already know are bad? Spend your time on learning to do better things! [...]

Best,

Marnen Laibow-Koser wrote:

Ralph Shnelvar wrote:

OK ... so I'm not supposed to use it but ...

Why doesn't rescue_from ActionController::RoutingError work witht he code from 7 Step Framework for Coding Skills Acquisition

Dude. You don't need to rescue from RoutingErrors -- Rails already handles that. You don't want to use restful_authentication -- Authlogic is better. Why are you so intent on figuring out how to do things that you already know are bad? Spend your time on learning to do better things! [...]

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

I will be using Authlogic ... that's not the issue.

I am trying to resolve why something that should work ... rescue_from ... doesn't work in one place but does in another.

Ralph Shnelvar wrote:

Marnen Laibow-Koser wrote:

Ralph Shnelvar wrote:

OK ... so I'm not supposed to use it but ...

Why doesn't rescue_from ActionController::RoutingError work witht he code from 7 Step Framework for Coding Skills Acquisition

Dude. You don't need to rescue from RoutingErrors -- Rails already handles that. You don't want to use restful_authentication -- Authlogic is better. Why are you so intent on figuring out how to do things that you already know are bad? Spend your time on learning to do better things! [...]

Best, -- Marnen Laibow-Koser http://www.marnen.org marnen@marnen.org

I will be using Authlogic ... that's not the issue.

No, that's not the issue. The issue is that you never need rescue_from RoutingError, since Rails already does that for you.

I am trying to resolve why something that should work ... rescue_from ... doesn't work in one place but does in another.

Because you're using it in a nonsensical way.

Let me turn the question around. Why do you think you need rescue_from RoutingError? What can you do with it that Rails' own error handling doesn't give you?

Best,

Let me turn the question around. Why do you think you need rescue_from RoutingError? What can you do with it that Rails' own error handling doesn't give you?

Do I need it? Probably not.

But since you asked ...

Perhaps I want to collect statistics and take appropriate action if a user is attempting to probe or attack my website for a security weakness.

Ralph Shnelvar wrote:

Let me turn the question around. Why do you think you need rescue_from RoutingError? What can you do with it that Rails' own error handling doesn't give you?

Do I need it? Probably not.

Then don't use it!

But since you asked ...

Perhaps I want to collect statistics and take appropriate action if a user is attempting to probe or attack my website for a security weakness.

I've never tried this, but apparently you want rescue_action or rescue_action_in_public .

Best,

Marnen Laibow-Koser wrote:

Ralph Shnelvar wrote:

Let me turn the question around. Why do you think you need rescue_from RoutingError? What can you do with it that Rails' own error handling doesn't give you?

Do I need it? Probably not.

Then don't use it!

But since you asked ...

Perhaps I want to collect statistics and take appropriate action if a user is attempting to probe or attack my website for a security weakness.

I've never tried this, but apparently you want rescue_action or rescue_action_in_public .

Just to let you know ... the authlogic code, rescue_test.rb, tests for   rescue_from ActionController::RoutingError with a comment that "# This is a Dispatcher exception and should be in ApplicationController."

Anyway, thanks for pointing to rescue_action and rescue_action_in_public. I'll research these.

Hi Ralph, I have to agree with Marnen on this issue; Rails already deals with routing errors pretty well. But, I understand that you may want to get your head around why the rescue_from ActionController::RoutingError call doesn't work in certain situations. I also understand the need to want to do something programmatically to log or handle the failed request.

I think that Marnen is on the right track in that what you are trying to accomplish with the rescue_from call isn't really the right way to approach the situation. You want either the rescue_action or rescue_action_in_public calls instead. I've never used them -- never had a need for them that I'm aware of -- but the API docs on these methods seem to tell me this is what you want instead of rescue_from.

I'm guessing here that you really want to be able to track and keep a record of all the URLs in your app/site that might trigger a 404 or could be considered "probing the armor" for weaknesses.

This may be a bit off from your original path, but have you considered trying to catch and trap all 404 errors? I use a technique derived from Advanced Rails Recipes (Pragmatic Bookshelf: By Developers, For Developers fr_arr) where I set up a glob route at the bottom of my routes.rb file:

map.connect '*path', :controller => 'four_o_fours'

Then create a controller and model to handle these requests:

Billee D. wrote:

Hi Ralph, I have to agree with Marnen on this issue; Rails already deals with routing errors pretty well. But, I understand that you may want to get your head around why the rescue_from ActionController::RoutingError call doesn't work in certain situations. I also understand the need to want to do something programmatically to log or handle the failed request.

Really, it was -- in the beginning -- a matter of curiosity as to WHY something didn't work rather than any great need to deal with an issue. It was, in addition, a general request for how one would go about solving why.

Suddenly, though, it morphed into a security issue that "I picked that out of the air" and realized that I really did want to deal with that security issue.

As a newbie, I find your comments so far very illuminating and helpful.

I think that Marnen is on the right track in that what you are trying to accomplish with the rescue_from call isn't really the right way to approach the situation. You want either the rescue_action or rescue_action_in_public calls instead. I've never used them -- never had a need for them that I'm aware of -- but the API docs on these methods seem to tell me this is what you want instead of rescue_from.

Ok, remembering that I am a newbie, please explain _why_ rescue_action is better/preferred/etc. than rescue_from.

I'm guessing here that you really want to be able to track and keep a record of all the URLs in your app/site that might trigger a 404 or could be considered "probing the armor" for weaknesses.

Speaking of this, I was delighted to find this relatively easy-to-read article on security issues that was installed in my authlogic sample.

... \authlogic\vendor\rails\railties\guides\source\security.textile

This may be a bit off from your original path, but have you considered trying to catch and trap all 404 errors? I use a technique derived from Advanced Rails Recipes (Pragmatic Bookshelf: By Developers, For Developers fr_arr) where I set up a glob route at the bottom of my routes.rb file:

It is off the original path but ... I like! I like!

map.connect '*path', :controller => 'four_o_fours'

Then create a controller and model to handle these requests:

[snip]

  def self.down     drop_table :four_o_fours   end end

==================================================

Set this up and you can have a fairly decent trace log of errant requests right in the database. You can also extend this logic and setup other controllers for different errors and more. For example, I have logic set up that will email me if a certain 404 error is accessed more than 10 times in a minute so I can either fix the problem or investigate the issue (e.g. a "probe" request).

Nice! Nice! Nice!

I guess this is all just to point out that routing errors are already pretty easy to manage and maybe what you are really trying to achieve requires a different approach. :slight_smile:

But ... I still don't understand why it is a better approach.

Clearly you and Marnen Laibow-Koser understand why rescue from is bad bad bad ... but I an still clueless as to what principle or principles I am breaking.

Ralph Shnelvar wrote:

Billee D. wrote:

Hi Ralph, I have to agree with Marnen on this issue; Rails already deals with routing errors pretty well. But, I understand that you may want to get your head around why the rescue_from ActionController::RoutingError call doesn't work in certain situations. I also understand the need to want to do something programmatically to log or handle the failed request.

Really, it was -- in the beginning -- a matter of curiosity as to WHY something didn't work rather than any great need to deal with an issue. It was, in addition, a general request for how one would go about solving why.

Suddenly, though, it morphed into a security issue that "I picked that out of the air" and realized that I really did want to deal with that security issue.

As a newbie, I find your comments so far very illuminating and helpful.

I think that Marnen is on the right track in that what you are trying to accomplish with the rescue_from call isn't really the right way to approach the situation. You want either the rescue_action or rescue_action_in_public calls instead. I've never used them -- never had a need for them that I'm aware of -- but the API docs on these methods seem to tell me this is what you want instead of rescue_from.

Ok, remembering that I am a newbie, please explain _why_ rescue_action is better/preferred/etc. than rescue_from.

Because it's clearly (from the docs etc.) the way the Rails designers intended this to be done. I don't know why rescue_from doesn't work on RoutingErrors -- I just know that it's not meant to work, and that there is another method, built for the purpose, that does work.

[...]

But ... I still don't understand why it is a better approach.

Clearly you and Marnen Laibow-Koser understand why rescue from is bad bad bad ... but I an still clueless as to what principle or principles I am breaking.

You're breaking the principle of working *with* the framework, not against it. If Rails provides something that does exactly what you want, you should use it rather than trying to reinvent a square wheel.

Best,

Clearly you and Marnen Laibow-Koser understand why rescue from is bad bad bad ... but I an still clueless as to what principle or principles I am breaking.

You're breaking the principle of working *with* the framework, not against it. If Rails provides something that does exactly what you want, you should use it rather than trying to reinvent a square wheel.

Ok ... I'm missing some gestalt.

Something is clear to you that is utterly unclear to me.

What in the docs clues you in to the fact that rescue_action is better than rescue_from? And/or that rescue_from might not work.

Ralph Shnelvar wrote:

Clearly you and Marnen Laibow-Koser understand why rescue from is bad bad bad ... but I an still clueless as to what principle or principles I am breaking.

You're breaking the principle of working *with* the framework, not against it. If Rails provides something that does exactly what you want, you should use it rather than trying to reinvent a square wheel.

Ok ... I'm missing some gestalt.

Something is clear to you that is utterly unclear to me.

What in the docs clues you in to the fact that rescue_action is better than rescue_from?

I did a Web search and found that that's what people are using for rescuing from RoutingError.

And/or that rescue_from might not work.

Your original post.

Best,

Interestingly enough, I generated a fresh rails 2.3.5 app, stuck

class ApplicationController < ActionController::Base   rescue_from ActionController::RoutingError, :with => :not_found   rescue_from ActionController::UnknownAction, :with => :not_found   protected   def not_found     render :text => 'Oh No!'   end end

in application_controller.rb and the rescue_from appears to work (ie going to /doesnotexist or /products/1/blahblah both produce oh no) (there is a slight difference between routing error and unknown action - the former means that rails doesn't thing the path corresponds to anything, the latter that rails thinks it is identified the controller & action for the request but the controller in question did not have the appropriate action. As far as the user is concerned these are both 404s but to rails these are slightly different)

Fred

Frederick Cheung wrote:

Frederick Cheung wrote: > Interestingly enough, I generated a fresh rails 2.3.5 app, stuck

> class ApplicationController < ActionController::Base > rescue_from ActionController::RoutingError, :with => :not_found > rescue_from ActionController::UnknownAction, :with => :not_found > protected > def not_found > render :text => 'Oh No!' > end > end

So .... what I think is happening is that I have a versioning problem with the restful authorization code.

Is there a way for me to see what version of the various components of the application I have?

Are you using the app checked in at Google Code Archive - Long-term storage for Google Code Project Hosting. essentially unmodified? That is using rails 2.0.2 (look at environment.rb) and rescue_from was only made to deal with RoutingError in july of 2008 (ie several months after that sample app was checked in), (if memory is correct that will mean that the first version it was in was rails 2.2)

Fred

Frederick Cheung wrote:

Are you using the app checked in at Google Code Archive - Long-term storage for Google Code Project Hosting. essentially unmodified?

YES!

That is using rails 2.0.2 (look at environment.rb) and rescue_from was only made to deal with RoutingError in july of 2008 (ie several months after that sample app was checked in), (if memory is correct that will mean that the first version it was in was rails 2.2)

I tracked through environment.rb with a debugger and   RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION RAILS_GEM_VERSION is undefined before the statement and is defined as   RAILS_GEM_VERSION = "2.0.2" afterwards.

I continued the run and immediately got the error - - - F:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer. rb:530:in `send': undefined method `cache_template_extensions=' for ActionView:: Base:Class (NoMethodError) - - -

So a little sniffing in the debugger and Google found http://paulsturgess.co.uk/articles/show/75-undefined-method-cache_template_extensions-when-upgrading-to-ruby-on-rails-222

Commending out the line   # config.action_view.cache_template_extensions = false in application.rb and voila ...

  rescue_from ActionController::RoutingError, :with => :route_not_found

now works.

I love you, Frederick Cheung. Please marry me.

- - - -

Now I have another decision to make. Do I use the autlogic code or the restful authorization code?

The Google Code Archive - Long-term storage for Google Code Project Hosting. code does a lot of stuff I want (e.g. email confirmation of the user's email account).

Yet ... I am reading a lot about why I should not use it.

Some advice, please.

Ralph Shnelvar wrote: [...]

I tracked through environment.rb with a debugger and   RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION RAILS_GEM_VERSION is undefined before the statement and is defined as   RAILS_GEM_VERSION = "2.0.2" afterwards.

Why did you need a debugger for that? That's the standard way of specifying Rails versions.

I continued the run and immediately got the error - - - F:/InstantRails-2.0-win/ruby/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer. rb:530:in `send': undefined method `cache_template_extensions=' for ActionView:: Base:Class (NoMethodError) - - -

So a little sniffing in the debugger and Google found http://paulsturgess.co.uk/articles/show/75-undefined-method-cache_template_extensions-when-upgrading-to-ruby-on-rails-222

Commending out the line   # config.action_view.cache_template_extensions = false in application.rb and voila ...

  rescue_from ActionController::RoutingError, :with => :route_not_found

now works.

I love you, Frederick Cheung. Please marry me.

- - - -

Now I have another decision to make. Do I use the autlogic code or the restful authorization code?

Why the hell would you use restful_auth? It has virtually no advantages over Authlogic and many disadvantages. I already explained this to you in some detail.

The Google Code Archive - Long-term storage for Google Code Project Hosting. code does a lot of stuff I want (e.g. email confirmation of the user's email account).

You should be able to do that pretty easily with Authlogic.

Yet ... I am reading a lot about why I should not use it.

Some advice, please.

I already gave you some in an earlier post. Perhaps you should go back and read it instead of acting like you never saw it. Remember: we'll help, but you have to read the help. It's not really fair to ask the same question multiple times.

Best,

Marnen Laibow-Koser wrote:

Ralph Shnelvar wrote: [...]

I tracked through environment.rb with a debugger and   RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION RAILS_GEM_VERSION is undefined before the statement and is defined as   RAILS_GEM_VERSION = "2.0.2" afterwards.

Why did you need a debugger for that? That's the standard way of specifying Rails versions.

Because, Marnen, what is utterly obvious to you ... what you know by experience or having read it somewhere, is something new to me.

Why the hell would you use restful_auth? It has virtually no advantages over Authlogic and many disadvantages. I already explained this to you in some detail.

And I explained that the restful code does email authorization. This is a fair amount of code for ME to write.

The Google Code Archive - Long-term storage for Google Code Project Hosting. code does a lot of stuff I want (e.g. email confirmation of the user's email account).

You should be able to do that pretty easily with Authlogic.

It may be easy for you. It is a huge undertaking for me.

There is state logic that I need to maintain (e.g. "email not confirmed") that I am not comfortable maintaining.

There is security code (e.g. the URL the user clicks on) that needs to be generated and responded to ... more state information.

The restful code sample ... http://code.google.com/p/simply-rich-authenticator ... uses "Acts As State Machine". Is this independent of the restful authentication and is it wise to use this in the Authlogic code?

Yet ... I am reading a lot about why I should not use it.

Some advice, please.

I already gave you some in an earlier post. Perhaps you should go back and read it instead of acting like you never saw it. Remember: we'll help, but you have to read the help. It's not really fair to ask the same question multiple times.

I have read your advice. You have advised ... without much background ... that authlogic is better. But is it better in the case where a more-or-less complete application has already been generated?

While you are obviously knowledgeable, following you advice without me having the appropriate background is difficult.

It appears to me that you have forgotten that it is the simple things that cause the greatest confusion.

Ralph Shnelvar wrote:

Marnen Laibow-Koser wrote:

Ralph Shnelvar wrote: [...]

I tracked through environment.rb with a debugger and   RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION RAILS_GEM_VERSION is undefined before the statement and is defined as   RAILS_GEM_VERSION = "2.0.2" afterwards.

Why did you need a debugger for that? That's the standard way of specifying Rails versions.

Because, Marnen, what is utterly obvious to you ... what you know by experience or having read it somewhere, is something new to me.

There is a comment explaining exactly this right in the environment.rb file that Rails generates for you. Surely you've looked in that file before...

Why the hell would you use restful_auth? It has virtually no advantages over Authlogic and many disadvantages. I already explained this to you in some detail.

And I explained that the restful code does email authorization. This is a fair amount of code for ME to write.

The Google Code Archive - Long-term storage for Google Code Project Hosting. code does a lot of stuff I want (e.g. email confirmation of the user's email account).

You should be able to do that pretty easily with Authlogic.

It may be easy for you. It is a huge undertaking for me.

I don't think you have to do it from scratch. IIRC, Authlogic provides e-mail activation in an even better way than restful_auth does.

There is state logic that I need to maintain (e.g. "email not confirmed") that I am not comfortable maintaining.

You don't need to.

There is security code (e.g. the URL the user clicks on) that needs to be generated and responded to ... more state information.

The restful code sample ... Google Code Archive - Long-term storage for Google Code Project Hosting. ... uses "Acts As State Machine". Is this independent of the restful authentication

5 seconds of Google searching will answer that.

and is it wise to use this in the Authlogic code?

I don't think you need to, although you probably could.

Yet ... I am reading a lot about why I should not use it.

Some advice, please.

I already gave you some in an earlier post. Perhaps you should go back and read it instead of acting like you never saw it. Remember: we'll help, but you have to read the help. It's not really fair to ask the same question multiple times.

I have read your advice. You have advised ... without much background ... that authlogic is better. But is it better in the case where a more-or-less complete application has already been generated?

Yes. First of all, you shouldn't be relying too heavily on cookbook code, and second, where did you get the idea that Authlogic sample apps don't also exist? In fact, they do.

While you are obviously knowledgeable, following you advice without me having the appropriate background is difficult.

Then feel free to ask questions or do independent research. I usually phrase my answers in such a way as to encourage such research. This is deliberate -- I prefer to guide rather than supply ready-made answers.

It appears to me that you have forgotten that it is the simple things that cause the greatest confusion.

I have not forgotten, and if anything I say is confusing, I will clarify it. But please meet me halfway by making a bona fide effort to research, experiment, and understand before looking up the answers in the back of the book. :slight_smile:

Best,