re: reachability of referer req:  Yes, if the screen that they had
just submitted the post req from that resulted in the failure had
previously been reached via a post req, then they wouldn't be sent
back to that particular page.  But, even if this were the case,
wouldn't (shouldn't?) the routing/rules you've defined for your app at
least redirect them to some other previous but related page via get?

Whenever possible, I try and structure my (non-ajax driven app)
screens such that each screen that contains a form that can result in
a post (or put or delete) req, or even handle user-input errors, that
screen is first rendered via a get request.  This allows for that bad
auth token redirect strategy to work.

re: recreate the params:  Yes, you could/would have to handle the
passing of the submitted params on to the redirected to screen
(controller meth) to handle for re-use/-render, but I've found such a
strategy becomes less viable the larger your app is (the more screens/
forms it contains that would need to be handled).

Bad auth token errors should be somewhat rare (unless it really is an
xss attack), so sending the user back to the screen where they came
from, letting them know there was a problem, and having them re-fill-
out the form and re-submit, seems like a reasonable enough way to
handle the problem imo (I haven't got any complaints from users so far
using this strategy).

Jeff

On Apr 15, 1:34 am, Max Williams <li...@ruby-forum.com> wrote:
> Jeff Burlysystems wrote:
> > Hi Max,
>
> > The strategy I usually follow is catch the error, log it (and check
> > logs periodically to make sure it's not really an xss attack), set a
> > msg for the user about the problem, and then redirect the user back to
> > where they came from, something along the lines of (in app/controllers/
> > application_controller.rb):
>
> Hi Jeff - thanks a lot.  I'd thought about sending them back to the
> previous (ie requesting-from) page but it seemed like the sort of thing
> that could be rather tricksy and problematic and generally a pandora's
> box of weird hard-to-predict problems.  I guess if it's been your
> strategy in the past then it's been ok for you?
>
> One problem i thought of was to do with request methods: the page they
> had been on might only be reachable from a post request for example, so
> just sending them back to the same url wouldn't work.  Similarly, you'd
> want to recreate the params they had on that page as well.  I've never
> used request.referer though, does it just handle all of that stuff
> automatically?
> --
> Posted viahttp://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en.

Reply via email to