Automatic 'verify :xhr => true' for methods ending with _xhr

Rails
1

hey guys,
i am writing a couple of actions which are only used with an xhr. I
‘protect’ them all against a direct access with the ‘verify’ method in
the controller

verify :only => …, :xhr => true

it would be cool if the system would automatically recognize the xhr
actions and protect them … i want to postfix methods with ‘_xhr’ and
those should be only accessible with an xhr.

  • good for readability
  • good for my DRY

does anyone has a tip on how to implement this? i guess it should go
into the ‘ApplicationController’

2

A before_filter is all you really need as that’s kinda what verify is
anyway

  • a DSL for creating before_filters.

before_filter :protect_xhr_methods

def protect_xhr_methods
redirect_to :action=>“index” unless self.action_name.include?("_xhr")
&&
request.xhr?
end

(I did not test this, and there’s a better way to test for _xhr in the
action name, but I am really lazy right now :slight_smile: )

Is that something close?

On Dec 3, 2007 1:42 PM, Michal G. <

3

yeah that was exactly what i needed… thanks…
the only problem i have now is that i have two before_filters:
before_filter :protect_xhr, check_login

and both can do a redirect … when protect_xhr does one already and
check_login also wants to do one i get a double response error …

whats the best solution for this?

4

In a filter, make sure to return false and not just to render /
redirect. You should always return false in a filter if you want to halt
the execution chain.

i.e redirect_to my_url and false

Michal G. wrote:

yeah that was exactly what i needed… thanks…
the only problem i have now is that i have two before_filters:
before_filter :protect_xhr, check_login

and both can do a redirect … when protect_xhr does one already and
check_login also wants to do one i get a double response error …

whats the best solution for this?

5

Brian H. wrote:

@Nathan:

While this is currently true, things have changed in Rails 2.0, and
that’s
where I’ve been working a lot lately. Thank you for reminding of this.

In Rails 2.0 you’ll no longer need to worry about that, as redirecting
or
explicitly rendering will stop the filter execution. (Yay!)

http://dev.rubyonrails.org/changeset/7984

hey thats great!! thanks for your participation

6

@Nathan:

While this is currently true, things have changed in Rails 2.0, and
that’s
where I’ve been working a lot lately. Thank you for reminding of this.

In Rails 2.0 you’ll no longer need to worry about that, as redirecting
or
explicitly rendering will stop the filter execution. (Yay!)

http://dev.rubyonrails.org/changeset/7984

7

On Dec 3, 2007 11:06 PM, Brian H. [email protected] wrote:

While this is currently true, things have changed in Rails 2.0, and that’s
where I’ve been working a lot lately. Thank you for reminding of this.

In Rails 2.0 you’ll no longer need to worry about that, as redirecting or
explicitly rendering will stop the filter execution. (Yay!)

http://dev.rubyonrails.org/changeset/7984

/me watches his Rails books depreciate even faster than last time

–
Greg D.
http://destiney.com/

8

Yea, I am aware that they changed that and I am really glad they did. I
always thought that the whole “returning false” thing was counter
intuitive. Everyone coming in expects a render or a redirect to stop the
execution. I always felt that was the better solution. Glad the rails
core finally agreed.

Brian H. wrote:

@Nathan:

While this is currently true, things have changed in Rails 2.0, and
that’s
where I’ve been working a lot lately. Thank you for reminding of this.

In Rails 2.0 you’ll no longer need to worry about that, as redirecting
or
explicitly rendering will stop the filter execution. (Yay!)

http://dev.rubyonrails.org/changeset/7984

9

Greg:

Just be glad you aren’t trying to follow the Agile book NOW, when
Rails 2.0is installed when you do a fresh installation :slight_smile: I feel
really sorry for any
newbies right now.