You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by José Santos <sa...@gmail.com> on 2009/03/23 13:53:59 UTC
avoiding unwanted value stack manipulation
hi,
what's the recommended design for avoiding fields of DTOs in the value stack
being updated through (HTML) DOM manipulation?
consider a typical edit page containing a form with some fields. this page
is a visual representation of a DTO we are about to update. the DTO is set
in the action - it was fetched from the database during prepare() - and
therefore is accessible from the value stack (the JSP generating the edit
page populated the form fields with corresponding DTO fields using OGNL).
by manipulating the DOM of the edit page (e.g. using Firebug) one can add a
new input field to the form. this input field may correspond to a DTO
read-only instance variable we would like the action *not* to update. upon
form submission, the DTO is updated with all the form fields (existing ones
+ the one added to the DOM) and persisted in the database.
there are several possible solutions to this issue:
solution 1: validate the DTO before persisting it in the database. the DTO
would be persisted only if no "read-only" fields were updated. this could be
achieved e.g. through a comparison between the updated DTO and a clone of
the original DTO (fetched during prepare()).
solution 2: another way to solve this would be to apply authorisation rules
in the model and therefore guarantee that certain DTO setters are
"read-only".
solution 3: use a DTO proxy object instead of the DTO itself. the DTO proxy
object would contain the DTO read-write fields only. the DTO would then be
updated with the corresponding DTO proxy fields before being persisted in
the database.
solution 4: not to use the "model-driven" approach and have setters in the
action corresponding to DTO read-write fields. the DTO would then be updated
with the corresponding action fields before being persisted in the database.
i am not considering a solution where setters of "read-only" fields are
removed from the DTO class as this would invalidate the update of those
fields by anyone (which includes users with higher privileges).
i would like to hear about your design solutions to this issue.
thanks in advance,
santos.
Re: avoiding unwanted value stack manipulation
Posted by Musachy Barroso <mu...@gmail.com>.
I would go for #4, you might want to look into
http://struts.apache.org/2.0.6/struts2-core/apidocs/com/opensymphony/xwork2/interceptor/ParameterNameAware.html,
or blocking params in the params interceptor.
musachy
On Mon, Mar 23, 2009 at 8:53 AM, José Santos <sa...@gmail.com> wrote:
> hi,
>
> what's the recommended design for avoiding fields of DTOs in the value stack
> being updated through (HTML) DOM manipulation?
>
> consider a typical edit page containing a form with some fields. this page
> is a visual representation of a DTO we are about to update. the DTO is set
> in the action - it was fetched from the database during prepare() - and
> therefore is accessible from the value stack (the JSP generating the edit
> page populated the form fields with corresponding DTO fields using OGNL).
>
> by manipulating the DOM of the edit page (e.g. using Firebug) one can add a
> new input field to the form. this input field may correspond to a DTO
> read-only instance variable we would like the action *not* to update. upon
> form submission, the DTO is updated with all the form fields (existing ones
> + the one added to the DOM) and persisted in the database.
>
> there are several possible solutions to this issue:
>
> solution 1: validate the DTO before persisting it in the database. the DTO
> would be persisted only if no "read-only" fields were updated. this could be
> achieved e.g. through a comparison between the updated DTO and a clone of
> the original DTO (fetched during prepare()).
>
> solution 2: another way to solve this would be to apply authorisation rules
> in the model and therefore guarantee that certain DTO setters are
> "read-only".
>
> solution 3: use a DTO proxy object instead of the DTO itself. the DTO proxy
> object would contain the DTO read-write fields only. the DTO would then be
> updated with the corresponding DTO proxy fields before being persisted in
> the database.
>
> solution 4: not to use the "model-driven" approach and have setters in the
> action corresponding to DTO read-write fields. the DTO would then be updated
> with the corresponding action fields before being persisted in the database.
>
> i am not considering a solution where setters of "read-only" fields are
> removed from the DTO class as this would invalidate the update of those
> fields by anyone (which includes users with higher privileges).
>
> i would like to hear about your design solutions to this issue.
>
> thanks in advance,
> santos.
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: avoiding unwanted value stack manipulation
Posted by José Santos <sa...@gmail.com>.
i tried solution 4 where the action:
- has the DTO itself as an instance variable (as opposed to having DTO
fields as instance variables)
- implements ParameterNameAware
it works ok with regard to parameter interception but the parameters are not
checked by validation annotations. this is because these parameters are set
in the DTO itself not in the action. so I have just implemented solution 4
as you suggested i.e. having parameters in the form corresponding to action
variables:
- the prepare() method gets the DTO and sets it in a private instance
variable (no DTO getter/setter)
- the save() method updates the private DTO with the read-writable
parameters set in the action
this way, the DTO is set with corresponding action variables which are
guaranteed to be:
- read-writeable: they belong to the white list of allowed parameters used
by acceptableParameterName() (interface ParameterNameAware)
- valid: they are checked by validation annotations
however, with this set up (parameters as instance variables instead of DTO
as instance variable) the acceptableParameterName() is no longer needed,
because the only setters available in the action are the ones corresponding
to read-writeable parameters.
i will leave actions implementing ParameterNameAware anyway. it's an extra
protection which may be helpful in cases where additional setters (either in
the action or in action subclasses) are added and one wants explicit control
over allowed parameters.
thanks again,
santos.
On Mon, Mar 23, 2009 at 2:12 PM, Nils-Helge Garli Hegvik
<ni...@gmail.com>wrote:
> The documentation for the ParametersInterceptor [1] mentions the
> ParameterNameAware interface [2]. Maybe that could be a solution?
>
> Nils-H
>
> [1] - http://struts.apache.org/2.1.6/docs/parameters-interceptor.html
> [2] -
> http://struts.apache.org/2.1.6/struts2-core/apidocs/com/opensymphony/xwork2/interceptor/ParameterNameAware.html
>
> On Mon, Mar 23, 2009 at 1:53 PM, José Santos <sa...@gmail.com>
> wrote:
> > hi,
> >
> > what's the recommended design for avoiding fields of DTOs in the value
> stack
> > being updated through (HTML) DOM manipulation?
> >
> > consider a typical edit page containing a form with some fields. this
> page
> > is a visual representation of a DTO we are about to update. the DTO is
> set
> > in the action - it was fetched from the database during prepare() - and
> > therefore is accessible from the value stack (the JSP generating the edit
> > page populated the form fields with corresponding DTO fields using OGNL).
> >
> > by manipulating the DOM of the edit page (e.g. using Firebug) one can add
> a
> > new input field to the form. this input field may correspond to a DTO
> > read-only instance variable we would like the action *not* to update.
> upon
> > form submission, the DTO is updated with all the form fields (existing
> ones
> > + the one added to the DOM) and persisted in the database.
> >
> > there are several possible solutions to this issue:
> >
> > solution 1: validate the DTO before persisting it in the database. the
> DTO
> > would be persisted only if no "read-only" fields were updated. this could
> be
> > achieved e.g. through a comparison between the updated DTO and a clone of
> > the original DTO (fetched during prepare()).
> >
> > solution 2: another way to solve this would be to apply authorisation
> rules
> > in the model and therefore guarantee that certain DTO setters are
> > "read-only".
> >
> > solution 3: use a DTO proxy object instead of the DTO itself. the DTO
> proxy
> > object would contain the DTO read-write fields only. the DTO would then
> be
> > updated with the corresponding DTO proxy fields before being persisted in
> > the database.
> >
> > solution 4: not to use the "model-driven" approach and have setters in
> the
> > action corresponding to DTO read-write fields. the DTO would then be
> updated
> > with the corresponding action fields before being persisted in the
> database.
> >
> > i am not considering a solution where setters of "read-only" fields are
> > removed from the DTO class as this would invalidate the update of those
> > fields by anyone (which includes users with higher privileges).
> >
> > i would like to hear about your design solutions to this issue.
> >
> > thanks in advance,
> > santos.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: avoiding unwanted value stack manipulation
Posted by Nils-Helge Garli Hegvik <ni...@gmail.com>.
The documentation for the ParametersInterceptor [1] mentions the
ParameterNameAware interface [2]. Maybe that could be a solution?
Nils-H
[1] - http://struts.apache.org/2.1.6/docs/parameters-interceptor.html
[2] - http://struts.apache.org/2.1.6/struts2-core/apidocs/com/opensymphony/xwork2/interceptor/ParameterNameAware.html
On Mon, Mar 23, 2009 at 1:53 PM, José Santos <sa...@gmail.com> wrote:
> hi,
>
> what's the recommended design for avoiding fields of DTOs in the value stack
> being updated through (HTML) DOM manipulation?
>
> consider a typical edit page containing a form with some fields. this page
> is a visual representation of a DTO we are about to update. the DTO is set
> in the action - it was fetched from the database during prepare() - and
> therefore is accessible from the value stack (the JSP generating the edit
> page populated the form fields with corresponding DTO fields using OGNL).
>
> by manipulating the DOM of the edit page (e.g. using Firebug) one can add a
> new input field to the form. this input field may correspond to a DTO
> read-only instance variable we would like the action *not* to update. upon
> form submission, the DTO is updated with all the form fields (existing ones
> + the one added to the DOM) and persisted in the database.
>
> there are several possible solutions to this issue:
>
> solution 1: validate the DTO before persisting it in the database. the DTO
> would be persisted only if no "read-only" fields were updated. this could be
> achieved e.g. through a comparison between the updated DTO and a clone of
> the original DTO (fetched during prepare()).
>
> solution 2: another way to solve this would be to apply authorisation rules
> in the model and therefore guarantee that certain DTO setters are
> "read-only".
>
> solution 3: use a DTO proxy object instead of the DTO itself. the DTO proxy
> object would contain the DTO read-write fields only. the DTO would then be
> updated with the corresponding DTO proxy fields before being persisted in
> the database.
>
> solution 4: not to use the "model-driven" approach and have setters in the
> action corresponding to DTO read-write fields. the DTO would then be updated
> with the corresponding action fields before being persisted in the database.
>
> i am not considering a solution where setters of "read-only" fields are
> removed from the DTO class as this would invalidate the update of those
> fields by anyone (which includes users with higher privileges).
>
> i would like to hear about your design solutions to this issue.
>
> thanks in advance,
> santos.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org