I''m sure this issue has been discussed already here, but I''m wondering how much of a sin you guys think it is that rails conventions encourage people to write actions that are executed with GET requests but alter the application state. On page 20 of the beta book, in the first real example of how rails actions work, they use a sample action that adds an item to a shopping cart with a GET request. Shouldn''t this technically be done with a POST? The user is already clicking on a button anyway, so it appears to the untrained eye that there is nothing in the app design that would preclude using POST instead (unless perhaps you wanted to have the item added to the cart with ajax or something). And even if you have a smart reason for doing it this way, wouldn''t it probably be a good idea at least to have a sidebar explaining to the reader why you have chosen to break this convention? Thanks, Carl
> I''m sure this issue has been discussed already here, but I''m wondering > how much of a sin you guys think it is that rails conventions > encourage people to write actions that are executed with GET requests > but alter the application state.It has been discussed at some length, esp. after the Google Web Accelerator debacle of a few weeks ago. DHH summed some of this up in an entry May 7: http://www.loudthinking.com/arc/000455.html And this entry at SVN seems to have been what kicked this conversation off in the first place: http://www.37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php> they use a sample action that adds an item to a shopping > cart with a GET request. Shouldn''t this technically be done with a > POST?Probably, in this case. Unfortunately, the only right answer to the general question of GETs vs. POSTS seems to be "it depends." There are surely cases where link-clicking GETs are fine.
On May 27, 2005, at 10:26 AM, Carl Youngblood wrote:> On page 20 of the beta book, in the first real example of how rails > actions work, they use a sample action that adds an item to a shopping > cart with a GET request. Shouldn''t this technically be done with a > POST? The user is already clicking on a button anyway, so it appears > to the untrained eye that there is nothing in the app design that > would preclude using POST instead (unless perhaps you wanted to have > the item added to the cart with ajax or something). And even if you > have a smart reason for doing it this way, wouldn''t it probably be a > good idea at least to have a sidebar explaining to the reader why you > have chosen to break this convention? >Agreed: I''m hoping DHH will give me a "David Says" on idempotent gets and Rails.
Is it possible to do POSTs with Ajax? If so, we could make all "destructive" ajax requests posts.... Dave Thomas wrote:> > On May 27, 2005, at 10:26 AM, Carl Youngblood wrote: > >> On page 20 of the beta book, in the first real example of how rails >> actions work, they use a sample action that adds an item to a shopping >> cart with a GET request. Shouldn''t this technically be done with a >> POST? The user is already clicking on a button anyway, so it appears >> to the untrained eye that there is nothing in the app design that >> would preclude using POST instead (unless perhaps you wanted to have >> the item added to the cart with ajax or something). And even if you >> have a smart reason for doing it this way, wouldn''t it probably be a >> good idea at least to have a sidebar explaining to the reader why you >> have chosen to break this convention? >> > > Agreed: I''m hoping DHH will give me a "David Says" on idempotent gets > and Rails. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 5/27/05, David Teare <dteare-LXYvB7aEQDJCkLs28/y7ANBPR1lH4CV8@public.gmane.org> wrote:> Is it possible to do POSTs with Ajax? If so, we could make all > "destructive" ajax requests posts....Yup. As Simon Willison found out (http://simon.incutio.com/archive/2005/05/06/bad), POSTs provide a false sense of security. I seriously doubt something like GWA (or any other legit link-prefetching product) would try to recreate malicious post requests. But, there''s always the possibility of someone sending out spam with these specially crafted links. And just to be picky, it''s not really "AJAX," just simple javascript. -- rick http://techno-weenie.net
I think the objection that RESTful development does not protect against malicious POSTs is a red herring. The point of RESTful development is not to protect against all types of attacks. It merely is a good convention to follow so that normal users and people who link to your site can easily know if a URL is safe to request without fear that it will cause unintended side effects. In that light I think that ajax POSTs should be used when side effects occur. There are other ways to protect against spam and the like if that becomes a problem. Carl On 5/27/05, Rick Olson <technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 5/27/05, David Teare <dteare-LXYvB7aEQDJCkLs28/y7ANBPR1lH4CV8@public.gmane.org> wrote: > > Is it possible to do POSTs with Ajax? If so, we could make all > > "destructive" ajax requests posts.... > > Yup. As Simon Willison found out > (http://simon.incutio.com/archive/2005/05/06/bad), POSTs provide a > false sense of security. > > I seriously doubt something like GWA (or any other legit > link-prefetching product) would try to recreate malicious post > requests. But, there''s always the possibility of someone sending out > spam with these specially crafted links. > > And just to be picky, it''s not really "AJAX," just simple javascript._______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I''m also thinking that it shouldn''t be too hard to make POST actions in rails as easy to do as GET actions. Any ideas? I''m not a rails pro yet... Is it possible to create a hrefs that do POSTs instead of GETs? I assume it would take a little javascript. Also, for those cases where an action link is an image or button instead of text, it would be easy to wrap a form around it. Carl On 5/27/05, Carl Youngblood <carl.youngblood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I think the objection that RESTful development does not protect against > malicious POSTs is a red herring. The point of RESTful development is not to > protect against all types of attacks. It merely is a good convention to > follow so that normal users and people who link to your site can easily know > if a URL is safe to request without fear that it will cause unintended side > effects. > > In that light I think that ajax POSTs should be used when side effects > occur. There are other ways to protect against spam and the like if that > becomes a problem. > > Carl > > On 5/27/05, Rick Olson <technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > On 5/27/05, David Teare <dteare-LXYvB7aEQDJCkLs28/y7ANBPR1lH4CV8@public.gmane.org> wrote: > > > Is it possible to do POSTs with Ajax? If so, we could make all > > > "destructive" ajax requests posts.... > > > > Yup. As Simon Willison found out > > (http://simon.incutio.com/archive/2005/05/06/bad), POSTs provide a > > false sense of security. > > > > I seriously doubt something like GWA (or any other legit > > link-prefetching product) would try to recreate malicious post > > requests. But, there''s always the possibility of someone sending out > > spam with these specially crafted links. > > > > And just to be picky, it''s not really "AJAX," just simple javascript. > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Carl Youngblood <carl.youngblood@...> writes:> > I''m also thinking that it shouldn''t be too hard to make POST actions > in rails as easy to do as GET actions.This is the goal of the ''button_to'' helper, which parallels the easy-to-use ''link_to'' helper but creates a POST-submitting form button instead of a link: http://community.moertel.com/ss/space/start/2005-05-08/1 I have submitted ''button_to'' as a RoR patch. I hope it will make it into the official sources soon: http://dev.rubyonrails.com/ticket/1371 Cheers, Tom
On 6/13/05, Tom Moertel <tom-RKvYLT2W2Q9BDgjK7y7TUQ@public.gmane.org> wrote:> This is the goal of the ''button_to'' helper, which parallels the > easy-to-use ''link_to'' helper but creates a POST-submitting form button > instead of a link:button_to doesn''t parallel link_to the way it''s named! "link" in "link_to" refers to the verb "link", not the noun. "submit_to" makes a lot more sense than "button_to" IMHO -- gavri http://livejournal.com/users/ga_woo
On 6/13/05, Gavri Fernandez <gavri.fernandez-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 6/13/05, Tom Moertel <tom-RKvYLT2W2Q9BDgjK7y7TUQ@public.gmane.org> wrote: > > This is the goal of the ''button_to'' helper, which parallels the > > easy-to-use ''link_to'' helper but creates a POST-submitting form button > > instead of a link: > > button_to doesn''t parallel link_to the way it''s named! > > "link" in "link_to" refers to the verb "link", not the noun. > "submit_to" makes a lot more sense than "button_to" IMHO+1> -- > gavri > http://livejournal.com/users/ga_woo > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Bill Guindon (aka aGorilla)
Tom Moertel wrote:> Carl Youngblood <carl.youngblood@...> writes: > >>I''m also thinking that it shouldn''t be too hard to make POST actions >>in rails as easy to do as GET actions. > > This is the goal of the ''button_to'' helper, which parallels the > easy-to-use ''link_to'' helper but creates a POST-submitting form button > instead of a link: > > http://community.moertel.com/ss/space/start/2005-05-08/1 > > I have submitted ''button_to'' as a RoR patch. I hope it will make it > into the official sources soon: > > http://dev.rubyonrails.com/ticket/1371 >I saw the mention of button_to in the second beta of the Rails book. I was initially puzzled, because to handle multiple submit buttons on a form requires a little work on the server side. Now I see that you are proposing to wrap a little form around each button. There may be some contexts in which this is a reasonable thing to do, but I would like to see Rails dealing with the more common requirement for multiple submit buttons on the *same* form first. regards Justin PS - I strongly support your comment on the first beta of the book.
Tom Moertel wrote:>Carl Youngblood <carl.youngblood@...> writes: > > >>I''m also thinking that it shouldn''t be too hard to make POST actions >>in rails as easy to do as GET actions. >> >> > >This is the goal of the ''button_to'' helper, which parallels the >easy-to-use ''link_to'' helper but creates a POST-submitting form button >instead of a link: > >why don''t we add a "post" option to link_to? This could generate some JS magic to do a post request and would avoid the nested-forms problem. I think there a valid reasons to prefer links over buttons because they don''t look so "intrusive". I know backpack is doing something along this lines (I believe they are using a hidden form somewhere on the page that is populated and submitted by JS). I hoped, they''d include this into rails. David, Jason, any chances you are doing this or should we reimplement it? Sebastian
Sebastian Kanthak wrote:> why don''t we add a "post" option to link_to? This could generate some JS > magic to do a post request and would avoid the nested-forms problem. I > think there a valid reasons to prefer links over buttons because they > don''t look so "intrusive".It is fashionable to use links instead of buttons, but it is bad from a usability perspective. The HTTP1.1 specification (IETF RFC 2616, http://www.faqs.org/rfcs/rfc2616.html ) says: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. The convention understood by users is that links are used to navigate (safely) and buttons are used to issue commands to the server. regards Justin
Sebastian Kanthak wrote:>Tom Moertel wrote: > > > >>Carl Youngblood <carl.youngblood@...> writes: >> >> >> >> >>>I''m also thinking that it shouldn''t be too hard to make POST actions >>>in rails as easy to do as GET actions. >>> >>> >>> >>> >>This is the goal of the ''button_to'' helper, which parallels the >>easy-to-use ''link_to'' helper but creates a POST-submitting form button >>instead of a link: >> >> >> >> >why don''t we add a "post" option to link_to? This could generate some JS >magic to do a post request and would avoid the nested-forms problem. I >think there a valid reasons to prefer links over buttons because they >don''t look so "intrusive". > >I know backpack is doing something along this lines (I believe they are >using a hidden form somewhere on the page that is populated and >submitted by JS). I hoped, they''d include this into rails. David, Jason, >any chances you are doing this or should we reimplement it? > > >And if the js is off in the browser... i think both are valid... personally i prefer the button_to _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails