> -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Lionel > Sent: Tuesday, September 07, 2004 9:32 AM > To: [EMAIL PROTECTED] > Subject: Re: A couple of questions > > > Jim Barrows wrote: > > > In much of my code I do: > > BeanUtils.copyProperties( dataVo, dataForm); > > and I'm done. Your way would require a lot more code. > > This seems great, but I can't do that because of user rights. > Some users don't have rights to update certain fields, so I > have to call > each setter manually :-( > As these forbiden fields are not present in the JSP (or > displayed readonly), > the dataVo would be updated with null values if I called > BeanUtils.copyProperties( dataVo, dataForm); > How do you manage this ?
I use a defense-in-depth strategy, starting at the UI, and going to the Business layer. I use coarse-grained form objects, but limit the fields on the page to what the user can actually change. Depending on complexity, I'll either use <c:if or <logic: tags for simple cases. If I have a lot of fields to check by user, then I'll use custom tags that inherit from <c: or <html: and add in the check to see what kind of field they're going generate (disabled html:text for instance, a <c:out or possibly nothing at all). This leaves me open[1] to users who can create and submit their own custom form, rather then the one they're getting of the web page. Since the action is only responsible for dealing with the UI, I use the Business layer as the hard security check for fields the user can or cannot change, fields they have to change and other such business logic, whether security related or not. I try and keep security violation messages to "xxx field is invalid", without saying why it's invalid. This prevents information leakage as to what fields are actually being protected. Now my users can game the UI all they want, and they still have to get through this second layer. Finally, if I'm really paranoid, I also keep track of what user has updated what fields, and use triggers and other database related tricks as my final layer of defense. This means that every DAO, first inserts a change record (typically, username, fieldname, new value(as string), old value(as string) and timestamp at a minimum with username and timestamp as pk), which the triggers bounce against the security table the BO uses. If that works, then the DAO goes ahead and makes the change, otherwise roll the transaction back.. log everything and send back some sort of catastrophic failure to the UI. Typically, I use database not found, not up or something similar with a message to contatct their sys ad. Basically if there is a security error at this point, give them absolutely nothing in the way of information, because they probably know to much as it is. [1]SQL injection attacks are handled by a security filter that monitors all incoming traffic for SQL statements, and are outside what I'm talking about. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
