struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nils-Helge Garli Hegvik <>
Subject Re: avoiding unwanted value stack manipulation
Date Mon, 23 Mar 2009 13:12:47 GMT
The documentation for the ParametersInterceptor [1] mentions the
ParameterNameAware interface [2]. Maybe that could be a solution?


[1] -
[2] -

On Mon, Mar 23, 2009 at 1:53 PM, José Santos <> 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:
For additional commands, e-mail:

View raw message