struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nils-Helge Garli Hegvik <nil...@gmail.com>
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?

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 <santos.swdev@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


Mime
View raw message