On 06-06-2010 at 10:36, Thomas Menke wrote: > Think of the following scenario: There is a form for editing a certain > entity stored in a database. The form contains a check box "delete this > entity" with the name delete. If the check box is checked, the entity > will be deleted when the user hits the save button. > Now a malicious user sends a link to a well meaning user to the form > "Could you have a look at this entity and change property x, it contains > a spelling mistake: http://example.com/edit.action?delete=1. Now when > the well meaning user clicks that link the delete check box will be > checked by default and if the user does not pay that much attention, the > entity will be gone forever and everyone will be very very startled who > deleted it... Nobody knows, maybe not even the well intentioned user. > The simplest fix to this problem that I can think of is to only use http > parameters if the request was an http POST instead of a GET. This would > not do any harm to the validation systems, because forms are usually > send by POST anyway and it is waaaay harder to trick well intentioned > users into making a certain POST request. > Or what is your opinion on that?
Even for such requests, I'd interpret the parameters in the URL in addition
to the POST parameters. My main reason is that is allows clean URL's, but
even without it still gives you more flexibility (I need that much
flexibility in about one in every 5 programs).
Having your ActionBean verify that destructive operations are only allowed
via a POST request are still a good idea though.
> I do like the "Action first" model and I placed all my JSP files in the
> WEB-INF directory to make them unavailable for direct calls. But I do
> have more than one action bean. In this case there are two action beans
> involved: The FormActionBean and the SaveActionBean. The FormActionBean
> loads an entity from the database if an id has been supplied (to
> prepopulate the form) and just displays the form. But the form does not
> submit to the FormActionBean. Instead the data is send to the
> SaveActionBean (<stripes:form beanclass="...SaveActionBean">...).
> I did this because at some point I got a little confused within my own
> code with all the @Validate(on={"foo","bar","foobar"}). To get rid of
> all the variable declarations that I don't need in certain methods I
> started putting every method in a separate action bean. Unfortunately I
> discovered that this breaks the automatic population of the form.
> Would you consider that bad practice what I am doing and advise me to
> always put the method that displays the form into the same ActionBean as
> the method that is executed on submit?
Instead of using different ActionBean's for one form, I prefer to use a
composite structure for both the JSP forms and the ActionBean classes (the
common parts go into a superclass / parent layout). This way I still have the
field separation, while also adhering to the "one JSP, one ActionBean"
design. In fact, my ActionBean classes and JSP pages always have the same
directory/package and 'inheritance' structure. Keeps things simpler.
Oscar
--
,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/
/() )
(__ ( If we don't believe in freedom of expression for people we despise,
=/ () we don't believe in it at all. -- Noam Chomsky
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
