Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (nike.apache.org: domain of nilsga@gmail.com designates
 209.85.220.163 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=B2go9lbCD6/o9KV2y/T7c/gxXP4GiVODOsatj/ji00uRM3f9/uBI0QnmHjs/vs02hr
         HGS7aZRbyYVv0u0E9ev+S1StXXTjmeArMz8D2PI/cw0VS9IYEUWg52m3og9bFM8OKLuS
         2kskG0Tc2nRRF9t64ZqP4OG1/W+Cdj8GUwWbw=
MIME-Version: 1.0
In-Reply-To: <d71b376c0903230553k4e189ec5lfe9c57c2d4fb5c25@mail.gmail.com>
References: <d71b376c0903230553k4e189ec5lfe9c57c2d4fb5c25@mail.gmail.com>
Date: Mon, 23 Mar 2009 14:12:47 +0100
Message-ID: <7270d7cd0903230612p3956748w6c2e31f90aabf1e4@mail.gmail.com>
Subject: Re: avoiding unwanted value stack manipulation
From: Nils-Helge Garli Hegvik <nilsga@gmail.com>
To: Struts Users Mailing List <user@struts.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=E9 Santos <santos.swdev@gmail.com> wro=
te:
> hi,
>
> what's the recommended design for avoiding fields of DTOs in the value st=
ack
> being updated through (HTML) DOM manipulation?
>
> consider a typical edit page containing a form with some fields. this pag=
e
> is a visual representation of a DTO we are about to update. the DTO is se=
t
> 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. upo=
n
> form submission, the DTO is updated with all the form fields (existing on=
es
> + 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 DT=
O
> 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 rul=
es
> 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 pro=
xy
> object would contain the DTO read-write fields only. the DTO would then b=
e
> 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 th=
e
> action corresponding to DTO read-write fields. the DTO would then be upda=
ted
> with the corresponding action fields before being persisted in the databa=
se.
>
> 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