Jeff Burlysystems wrote: > 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? Yes, they *should*. :)
> 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. Yeah, again that's all good app design. I try to do this as well, you just reminded me that i should add 'go to the current contents of the address bar and see if anything weird happens' to my test scripts. > 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). I think this is covered under the last point really: if all the pages are 'reload-safe' then it's not so much of an issue. Thanks a lot. i think the lesson generally is 'if you've designed your app properly then it's fine'. Which is good to know. cheers, max -- Posted via http://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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
