Controller filters just got a little update that may mess with your flow. As of now, returning false no longer halts the execution of the action chain. Instead, rendering or redirecting is what automatically stops the action chain.
If you think about it, it makes sense that rendering or redirecting within a filter signals the abortion of normal action execution since you can only render/redirect once per call and doing so reasonably indicates that no more processing is required.
So where before you might have had a filter such as:
1 2 3 4 5 6 |
def must_be_logged_in if(not user_logged_in?) redirect_to login_url return false end end |
You can now let the act of rendering or redirecting imply completion instead of returning false:
1 2 3 |
def must_be_logged_in redirect_to login_url if not user_logged_in? end |
At first blush I thought this might mess up existing filters, but a quick review of mine indicated that whenever I return false I’ve already rendered or redirected. Not sure if this holds true for everybody or not…
tags: ruby, rubyonrails
Thanks for the heads up.
This also has the nice additional benefit that a filter that ends with an expression that evaluates to a boolean doesn’t accidentally mess up the flow.
For example, I use the following filter in conjunction with the restful_authentication plugin to provide @logged_in for use in my views:
[code] def determine_whether_logged_in @logged_in = logged_in? true # required prior to this fix in order to ensure rendering continues end [/code]
Discovering I needed the additional line took quite a while, as I’m new to Ruby/Rails!
Good point, Ryan!!!
I think there’s many people using ‘return false’ to block access to a controller (including myself)!!
Thanks for warning me! I’ll check all my filters before I get any trouble!!
Felipe Giotto Inovare Development Team
Oh wow, thanks for that heads up; I definitely have some code to spice up now. Thanks again!
I’d love to see some real-world filters that just returns false without a render or a redirect. Even in case of security violations, you should at the very least be returning an HTTP status code using head(). Just returning false will give you the White Screen of Death. Which was probably never a good idea.
I am building a course management system using ROR. For that a class can have assignments, lectures, files etc. Now, both assignments and lectures have more or less same functionalities. So, if I want to extend this from a common class say Files, so how would i go for writing the controller and model for files, assignment and lectures. Can you please help me in that.
Of course I had few filters that returned false together with the white screen of death. I even had a TODO item “Fix the white screen with nice error message when registration is not allowed”. Fortunately, I also have lots of functional tests. Few of them did not play well with the Rails 2.0 upgrade. 20 minutes of fighting with filters and one enlightenment later (I remember reading something about different filter handling…) and v’oila, I’m here reading all I need to know about it!
Thanks for the heads up.