# Before\_filter chains and halting at an arbitrary filter **URL:** \ **Category:** Rails\ **Created:** [July 18, 2006, 9:10pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890 "2006-07-18T21:10:29Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 9:10pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/1 "2006-07-18T21:10:29Z")
Hi–I’m trying to implement a 2-level authentication system, where I have one before\_filter which does general user authentication, and another which does further authorization for a specific controller. I have it set up as follows: before\_filter :authorize\_level\_2 prepend\_before\_filter :authorize\_level\_1 which causes authorize\_level\_1() to run, and then authorize\_level\_2(). However, the problem is that I want, if authorize\_level\_1 decides to redirect someone back to the login page, to not run authorize\_level\_2. Unfortunately it looks like this is what happens, and since authorize\_level\_2 needs to assume information only available when authorize\_level\_1 has succeeded, I get errors. Is there any way to halt execution of further filters if some condition is satisfied? I would have though redirect\_to() would have this effect, but it appears that code is still executed after a redirect\_to() ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 9:23pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/2 "2006-07-18T21:23:28Z")
“Jonathan L.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote in message news:removed\_email\_address@domain.invalid… > However, the problem is that I want, if authorize\_level\_1 decides to > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). > Hi Jonathan if you return false from a before filter, it stops the execution of subsequent filters. So returning false after your call to redirect\_to should do the trick hth alan ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 9:23pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/3 "2006-07-18T21:23:49Z")
On 7/18/06, Jonathan L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Is there any way to halt execution of further filters if some condition > is satisfied? I would have though redirect\_to() would have this effect, > but it appears that code is still executed after a redirect\_to() redirect\_to … return false ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 9:54pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/4 "2006-07-18T21:54:08Z")
Thanks to everyone for kindly responding. Sorry I didn’t know the question had been answered recently (search for the mailing list appears to be down). You’d think a simple behavior for filters like this would be included in the RoR docs! My code works wonderfully now. -Jonathan ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 10:02pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/5 "2006-07-18T22:02:56Z")
On 7/18/06, Jonathan L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks to everyone for kindly responding. Sorry I didn’t know the > question had been answered recently (search for the mailing list appears > to be down). > > You’d think a simple behavior for filters like this would be included in > the RoR docs! My code works wonderfully now. [http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html](http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html) Look under “Filter chain ordering”. – James ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 11:43pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/6 "2006-07-18T23:43:58Z")
> [http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html](http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html) > > Look under “Filter chain ordering”. > > – James Ah, thanks. I know I looked at that section 5 or 6 times; must have breezed over the last two sentences assuming they were talking more about ordering per se and not about breaking the order. My fault! ---
**Author:** ![johanatan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8491ac/32.png) [@johanatan](https://www.ruby-forum.com/u/johanatan)\ **Post date:** [July 18, 2006, 9:33pm UTC](https://www.ruby-forum.com/t/before-filter-chains-and-halting-at-an-arbitrary-filter/98890/7 "2006-07-18T21:33:49Z")
Jonathan L. wrote: > However, the problem is that I want, if authorize\_level\_1 decides to > redirect someone back to the login page, to not run authorize\_level\_2. > Unfortunately it looks like this is what happens, and since > authorize\_level\_2 needs to assume information only available when > authorize\_level\_1 has succeeded, I get errors. > > Is there any way to halt execution of further filters if some condition > is satisfied? I would have though redirect\_to() would have this effect, > but it appears that code is still executed after a redirect\_to() I had the exact same problem a few weeks ago. I blogged about the solution here [http://blog.mattmargolis.net/articles/2006/07/02/halting-before\_filter-chains](http://blog.mattmargolis.net/articles/2006/07/02/halting-before_filter-chains) In short you basically just need to return false. Matthew M. [blog.mattmargolis.net](http://blog.mattmargolis.net)