> -----Original Message-----
> From: Joe Hertz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 25, 2004 9:22 AM
> To: 'Struts Users Mailing List'
> Subject: RE: ActionForm and Transfer Object
> 
> 
> > > 1) If you have a page which will update field A, but have 
> > > field B as hidden,
> > > and while the user on this screen is on the phone, someone 
> > > else updates
> > > field B, when the user saves his record, the other guy's 
> > > field B will be
> > > overwritten.
> > 
> > You have this race condition with the fields you are allowing 
> > to be changed as well.  It's a well known problem, with 
> > several solutions.  It's not jsut a problem with hidden fields.
> 
> Oh, absolutely. Didn't try to imply otherwise, but in this 
> case, it's really
> bad. It's the back door into the whole app.

I don't see it as anymore of a security risk, and somewhat less, then allowing users 
to edit fields.   The user has to go to a lot of trouble to spoof the app with hidden 
fields, as opposed to text fields.  If they are going to that level of trouble, hidden 
fields are the least of your concerncs.  Every field is vulnerable, hidden or not.
If I use hidden fields, I typically still add them into the validation, and the 
business logic still treats the object as if the whole thing was exposed, not just 
pieces.
If I'm really paranoid, I'll use a session attribute to store the original.  I really 
don't like hitting the DB anymore then necessary.  YMMV.  
If I have a business requirement that a user can only access certain fields, then I'll 
hit the DB again in the Business layer to do that check.

> 
> Yes, youre letting the user update everything regardless of state, but
> because of putting the current data into hidden fields, youre 
> ALSO letting
> him see what the fields are to update (including their current values,
> regardless of what he's supposed to be able to see).
> 
> So even if you checked the state before you updated 
> everything from what the
> html had (why you would do this, and not use the current 
> database state, I
> don't know), you'd still be letting the user see everything. 
> By not checking
> at all, youre now potentially giving him complete front end 
> access to your
> database.


> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to