> -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Lionel > Sent: Tuesday, September 07, 2004 10:30 AM > To: [EMAIL PROTECTED] > Subject: Re: A couple of questions > > > Jim Barrows wrote: > >> How do you manage this ? > > > > I use a defense-in-depth strategy, starting at the UI, and going to > > the Business layer. > > as I do. > > > 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). > > I use struts-layout tags and set the display field mode for > each field of > for the whole form in the Action. > > > 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. > > so you can't use copyProperty neither, and have to call manually the > authorized setters depending on user rights.
No, I validate the VO only has fields modified that the user can change, and it throws an exception. The action copies the form as is to the VO. So, I grab the original from the database, compare it to what the BO has been sent, and if it's different check the user authorization. This also allows an easy check for update race conditions. > > I would like to do it automatically: I would define somewhere > which fields > are updatable by each profile, and then call a single method like > copyProperties which would call only authorized setters . Actually you can do that with BeanUtils... I forget which class or method, I think it's populate or something similar. I would still do the verify in the business layer though, rather then the action. > This would simplify the code in the action for huge forms > accessible to many > profiles which contain hundreds of if(user is admin) else if(user is > manager) else if user is external else....which are hard to > maintain and to > update. That's why I do it in the business layer. I've done it with properties files, where each field was VO.fieldName=list, of, roles. I've simulated the same thing in DB's. Haven't done it in XML files, or with Spring yet. Hmmmm.... maybe tonight... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
