I'll buy that, but users should understand that malicious users can put HTML like this on other sites:
<img src="http://yoursite/deleteAccount";> That's not to say that POSTs are 100% immune to this sort of thing. They're just slightly less susceptible. The safe solution is to emded some sort of unique token in the URL, but I'll leave that topic for another day. This is why I went on to say, "or we could set the mode based on an annotation on the action method. Or some other way... " My thinking is we could set the mode based on GET/POST and let users override it in the Struts configuration or using annotations. Bob On 4/18/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > I decided to pull this out to the mailing list to keep Rough Spots > page [1] cleaner. > > crazybob: "Come up with a clean way to separate "view" actions from > "update" actions. ... [As one of the options] we could flag action > invocations as "view" or "update" (using an enum). We could > automatically choose a mode based on whether the request is an HTTP > GET or POST." > > MichaelJ: "Using GET for render and POST for submit works well unless > you want to trigger event with a link." > > crazybob: "Triggering an event should still be a POST (though the > framework should make it easy). From the HTTP spec.: 'GET and HEAD > methods SHOULD NOT have the significance of taking an action other > than retrieval.'" > > What actually should be done by a particular developer of a particular > application is a religious question. There is no legal way known to me > that allows to send POST request via a link without using Javascript. > Web applications take actions and change their state using links all > the time. Heck, take any web-based client, be it GMail or Yahoo, they > use links. Take CRUD application, the view/edit/delete actions are > usually made with links because putting three buttons on every line > would look ugly (well, modern apps use Javascript and highlighing, but > this is another story). I've been there and came back. Yes, using POST > is cleaner HTTP-wise, but the goal of a framework is to simplify > programmers' job, not to prohibit them from doing something. > > Also if you noticed, HTTP spec says "SHOULD NOT", not "MUST NOT". So, > using GET is not prohibited, it is simply frowned upon, but as I said > everyone uses links for actions and state change. > > Therefore, while a framework should teach good practices, it should > not prohibit from something that is technically feasible, but just > unacceptable for framework designers. I don't want framework to work > against me. Need no gods (have I already said that?) > > So, as you responded, triggering an event *should* be a POST, but it > is not like it *must be*. Framework should allow to use both POST and > GET to trigger an event. Obviously, using POST vs. GET as a division > point between submit and render is simple. Therefore it might be > sensible to agree, that POST always triggers input phase, while GET > requires further screening. > > I suggest taking a look at EventActionDispatcher [2] class and its > usage in Struts 1.x [3]. Basically, you define events that an action > (sorry, actionbean) responds to. If event is found in the request, > this is input phase. Appropriate event handler is called, as well as > validation/conversion (though I would really-really prefer to call > validation/conversion/etc manually without having to implement a bunch > of interfaces). If event is not found, then this is a render phase. > Plain and simple. > > Michael. > > [1] http://wiki.apache.org/struts/RoughSpots > [2] http://wiki.apache.org/struts/EventActionDispatcher > [3] http://wiki.apache.org/struts/DataEntryForm > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
