> -----Original Message----- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 5:40 AM > To: Struts Users Mailing List > Subject: Re: ActionForm with all application attributes > > > Bill, wait a minute, i just thought on something. > I wouldn't matter if a hacker set a attributes in my > BaseActionFomr, if i don't use it to build my DTOs. I > mount my DTOs case specific, so i'd just ignore the > hacker set attribute. > But if this hacker set attribute is in my DTO, i agree > that i could get problems. But if this attribute is > present in the DTO it means that even if i was using > the traditional way this attribute would present in > the traditional ActionForm and, consequently, would be > suceptible to the same problem. > Got the point???
Why give them any hooks you don't have to? Sure today you're not using the field, what about tomorrow? If the field isn't there in the form, then struts won't copy the attacking value into it, and you won't have to worry about it at all. > > > --- Bill Siggelkow <[EMAIL PROTECTED]> escreveu: > > > Are all of your getters and setters public? If so, > > (which I assume is > > true), one disadavantage is that request parameters > > can be passed in > > that set stuff on the form that you may not be > > expecting. For example, > > suppose your uber form supports properties for 'foo' > > 'bar' and 'baz'. > > > > Let's say one form sets the first two properties -- > > from a GET you would > > see: > > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob > > > > Now suppose some hacker comes along and does the > > following: > > > > > http://localhost/myapp/SubmitFooBar.do?foo=blah&bar=glob&baz=evilvalue > > > > Now, the property for baz has been set when you > > weren't expecting it to. > > > > - Bill Siggelkow > > > > > > Leandro Melo wrote: > > > > > Hi, > > > i sent this question yesterday, but as nowbody > > > answered me, i trying it again with a more > > > sifinificant title (sorry for the re-post). > > > Also, if i'm doing something terrible, i'd like to > > > know. > > > > > > Keeping in mind that more than one action form may > > > have to validate and/or reset the same fields, i > > > decided to this. > > > > > > I already have a MyBaseActionForm which > > incorporates > > > all > > > some methods that i need in my application. I > > don't > > > use Validator, as i prefer to use java classes for > > > validation ligth business logic. > > > > > > Now, i decided to add ALL fileds (setters and > > > getters) > > > i have in my application as private members of > > this > > > MyBaseActionForm. > > > > > > Then i created classes WebValidation and WebReset. > > > This classes have validate methods for all fields > > in > > > my application. These classes can access the > > fields > > > they need for each method because all my action > > > forms > > > extend the MyBaseActionForm, thus this > > WebValidation > > > and WebReset classes can call the setters and > > > getters > > > of an y action form to validate with the light > > > business logic i need. > > > > > > I got with this approach a centralized way and > > > "component" responsible for the validation. All my > > > action forms delegate the validate and reset > > methods > > > to the classes i mentioned. > > > > > > I'd like to briefly describe some nice > > > benefits of this approach. > > > > > > - With this approach i definetly solve my earlier > > > problem that i posted on question "1:N > > relationships - > > > ActionForm x DTOs". > > > > > > - With this approach i got no coupling between my > > > ActionForm and DTOs. > > > > > > - With this approach i have a centralized validate > > > unit. It's very usual to have more than 1 action > > form > > > validating the same field, what may causes some > > > duplication and a harder maintenance. A central > > unit > > > of validation and resetting suits this problem > > very > > > well. > > > > > > - With this approach i can perform light business > > > validation that must be done in java code. So, for > > one > > > or more situation i could access some util classes > > > that do some validation for me. > > > > > > - With this approach i have very small action > > forms > > > that basically has a validate and reset methods > > that > > > just delegate to the WebValidation and WebReset > > > classes. > > > > > > - With this approach i also have a central unit of > > > fields and their types, so if it's necessary to > > chance > > > them, i don't need to go through all the action > > forms > > > that have these fields. > > > > > > This approach will only work correctly if you > > don't > > > have fields with the same name in your > > application. > > > Naturally, this is not a drawback because forces > > you > > > to use a nice use of software engineering forcing > > you > > > to give significant names for the fiels. > > > > > > Well, i'd appreciate comments (bad or nice ones) > > on > > > that. > > > > > > Thanks, > > > Leandro > > > > > > > > > > > > > > > > > > > > > _______________________________________________________ > > > Yahoo! Acesso Grátis - navegue de graça com > > conexão de qualidade! > > > http://br.acesso.yahoo.com/ > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
