RE: Exposing ActionForm and MVC fields
Well, i actually end up doing the update only on the required fields on my ejb layer. This way, i don't need to worry about the exposure of the ActionForm fields. --- "Freddy Villalba A." <[EMAIL PROTECTED]> escreveu: > Hi, > > > I believe you shouldn't abuse neither from the MVC > pattern or the Struts' > framework. All the issues regarding buyer's actions > as well as seller's are > part of an specific area: workflow management. > > Implement a basic WF Management subsystem (or > integrate one into your > application), define the roles (buyer / seller / > whatever...), the actions > (along with the corresponding pre- and post-), the > nodes, etc... and yes, > have your presentation layer (Struts) integrate with > it. I know it's not > simple or cheap... yet, I'm almost convinced that, > at the end, it would've > been a good investment for you and your project. > > Save yourself from trying to convert Struts into an > all-mighty-god-who-knows-and-solves-everything tool. > > For me, that's the bottom-line for all these issues. > > Again, just my oppinion. HTH. > > Cheers, > Freddy. > > > -Mensaje original- > De: David Suarez [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 15 de octubre de 2004 17:06 > Para: [EMAIL PROTECTED]; Struts Users Mailing List > Asunto: RE: Exposing ActionForm and MVC fields > > > How about creating a hash/digest when you send the > page down with your > read-only fields and save it to session/hidden (you > know the +/-), then > compare it on the re-submit to see if any of the > values have changed. > If so, throw SecurityException or something similar? > > Would that work for you...djsuarez > > -Original Message- > From: Lee Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, October 15, 2004 8:52 AM > To: Struts Users Mailing List > Subject: Re: Exposing ActionForm and MVC fields > > > In this case, i`m still suceptible to be > > hacked by javascript, because of the ActionForm > fields > > exposure. > > What about that??? > > Different actions. I'd reccomend a dispatch action > class...with > different methods depending on whether the buyer or > seller submitted. > That way, in the seller method, even if they did > hack the submit form > you action would not be doing anything with those > fields. > > Lee > > > - > 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] > > __ 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]
RE: Exposing ActionForm and MVC fields
It's seems allright. --- David Suarez <[EMAIL PROTECTED]> escreveu: > How about creating a hash/digest when you send the > page down with your > read-only fields and save it to session/hidden (you > know the +/-), then > compare it on the re-submit to see if any of the > values have changed. > If so, throw SecurityException or something similar? > > Would that work for you...djsuarez > > -Original Message- > From: Lee Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, October 15, 2004 8:52 AM > To: Struts Users Mailing List > Subject: Re: Exposing ActionForm and MVC fields > > > In this case, i`m still suceptible to be > > hacked by javascript, because of the ActionForm > fields > > exposure. > > What about that??? > > Different actions. I'd reccomend a dispatch action > class...with > different methods depending on whether the buyer or > seller submitted. > That way, in the seller method, even if they did > hack the submit form > you action would not be doing anything with those > fields. > > Lee > > > - > 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]
RE: Exposing ActionForm and MVC fields
Hi Freddy, i agree with you in parts. Actually, i don`t have a formal workflow graph, but i do have it in some sketches. I think the point here is more about workflow implementations details, isn`t it??? --- "Freddy Villalba A." <[EMAIL PROTECTED]> escreveu: > Hi, > > > I believe you shouldn't abuse neither from the MVC > pattern or the Struts' > framework. All the issues regarding buyer's actions > as well as seller's are > part of an specific area: workflow management. > > Implement a basic WF Management subsystem (or > integrate one into your > application), define the roles (buyer / seller / > whatever...), the actions > (along with the corresponding pre- and post-), the > nodes, etc... and yes, > have your presentation layer (Struts) integrate with > it. I know it's not > simple or cheap... yet, I'm almost convinced that, > at the end, it would've > been a good investment for you and your project. > > Save yourself from trying to convert Struts into an > all-mighty-god-who-knows-and-solves-everything tool. > > For me, that's the bottom-line for all these issues. > > Again, just my oppinion. HTH. > > Cheers, > Freddy. > > > -Mensaje original- > De: David Suarez [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 15 de octubre de 2004 17:06 > Para: [EMAIL PROTECTED]; Struts Users Mailing List > Asunto: RE: Exposing ActionForm and MVC fields > > > How about creating a hash/digest when you send the > page down with your > read-only fields and save it to session/hidden (you > know the +/-), then > compare it on the re-submit to see if any of the > values have changed. > If so, throw SecurityException or something similar? > > Would that work for you...djsuarez > > -Original Message- > From: Lee Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, October 15, 2004 8:52 AM > To: Struts Users Mailing List > Subject: Re: Exposing ActionForm and MVC fields > > > In this case, i`m still suceptible to be > > hacked by javascript, because of the ActionForm > fields > > exposure. > > What about that??? > > Different actions. I'd reccomend a dispatch action > class...with > different methods depending on whether the buyer or > seller submitted. > That way, in the seller method, even if they did > hack the submit form > you action would not be doing anything with those > fields. > > Lee > > > - > 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] > > __ 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]
RE: Exposing ActionForm and MVC fields
Hi, I believe you shouldn't abuse neither from the MVC pattern or the Struts' framework. All the issues regarding buyer's actions as well as seller's are part of an specific area: workflow management. Implement a basic WF Management subsystem (or integrate one into your application), define the roles (buyer / seller / whatever...), the actions (along with the corresponding pre- and post-), the nodes, etc... and yes, have your presentation layer (Struts) integrate with it. I know it's not simple or cheap... yet, I'm almost convinced that, at the end, it would've been a good investment for you and your project. Save yourself from trying to convert Struts into an all-mighty-god-who-knows-and-solves-everything tool. For me, that's the bottom-line for all these issues. Again, just my oppinion. HTH. Cheers, Freddy. -Mensaje original- De: David Suarez [mailto:[EMAIL PROTECTED] Enviado el: viernes, 15 de octubre de 2004 17:06 Para: [EMAIL PROTECTED]; Struts Users Mailing List Asunto: RE: Exposing ActionForm and MVC fields How about creating a hash/digest when you send the page down with your read-only fields and save it to session/hidden (you know the +/-), then compare it on the re-submit to see if any of the values have changed. If so, throw SecurityException or something similar? Would that work for you...djsuarez -Original Message- From: Lee Harrington [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 8:52 AM To: Struts Users Mailing List Subject: Re: Exposing ActionForm and MVC fields > In this case, i`m still suceptible to be > hacked by javascript, because of the ActionForm fields > exposure. > What about that??? Different actions. I'd reccomend a dispatch action class...with different methods depending on whether the buyer or seller submitted. That way, in the seller method, even if they did hack the submit form you action would not be doing anything with those fields. Lee - 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]
RE: Exposing ActionForm and MVC fields
How about creating a hash/digest when you send the page down with your read-only fields and save it to session/hidden (you know the +/-), then compare it on the re-submit to see if any of the values have changed. If so, throw SecurityException or something similar? Would that work for you...djsuarez -Original Message- From: Lee Harrington [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 8:52 AM To: Struts Users Mailing List Subject: Re: Exposing ActionForm and MVC fields > In this case, i`m still suceptible to be > hacked by javascript, because of the ActionForm fields > exposure. > What about that??? Different actions. I'd reccomend a dispatch action class...with different methods depending on whether the buyer or seller submitted. That way, in the seller method, even if they did hack the submit form you action would not be doing anything with those fields. Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing ActionForm and MVC fields
If you're that concerned about it, then it's worth the effort to use different form beans that only expose the properties you feel comfortable with. I remember reading somewhere that BeanUtils will only copy properties that are present in both beans, so that would help you transfer values between the superset business object and the form bean subset. On Fri, 15 Oct 2004 11:53:20 -0300 (ART), Leandro Melo <[EMAIL PROTECTED]> wrote: > Do you other sugestion then Hubert? > > --- Hubert Rabago <[EMAIL PROTECTED]> escreveu: > > > > Hmm... you'd have to check how BeanUtils works if > > you do this. > > BeanUtils will just copy properties without checking > > for the declared > > type, and in fact it can't check for the declared > > type. Even if you > > just pass an interface declaration, the instance > > itself will expose > > the properties and BeanUtils will still populate > > them. > > > > > *** > > > This e-mail and its attachments are not > > confidential > > > and are intended for anyone who will believe what > > > I've written without holding me liable. > > > If this has come to you in error, please > > > don't notify me at any given time and just delete > > this > > > e-mail from your system. > > > You must take no action that you will blame me for > > > later, though if you want you can copy or disclose > > > > > it or any part of its contents to any person or > > organisation. > > > Statements and opinions contained in this email > > may > > > not necessarily represent those people who > > > pay me. Please note that e-mail > > > communications may be monitored by those > > > who have nothing better to do than read other > > people's e-mail. > > > > > > > On Fri, 15 Oct 2004 15:24:21 +0100, McCormack, Chris > > <[EMAIL PROTECTED]> wrote: > > > Like this: > > > > > > MainDataObj implements ISeller, IBuyer > > > > > > Seller implements ISeller > > > > > > Buyer implements IBuyer > > > > > > Seller seller = (ISeller)mainDataObj; > > > > > > then add seller to the request and populate your > > form from that for the Seller view and vice versa > > for the Buyer view. > > > > > > Friday pub lunch may have tarred my brain but I > > think that will work :) > > > > > > Chris > > > > > > > > > > > > -Original Message- > > > From: Leandro Melo > > [mailto:[EMAIL PROTECTED] > > > Sent: 15 October 2004 14:49 > > > To: Struts Users Mailing List > > > Subject: RE: Exposing ActionForm and MVC fields > > > > > > Hi Chris, what do you mean by "interfaces to > > filter" > > > (sorry for the stupidness)??? > > > Is it an ordinary Servlet filter?? > > > If so, i remember once using a few filters but i > > > coulnd`t get a reference to the request it self, > > only > > > to the context as a whole. Could you give an > > example? > > > > > > --- "McCormack, Chris" > > > <[EMAIL PROTECTED]> escreveu: > > > > Look at using interfaces to filter the sensitive > > > > data away from each user when putting the data > > > > object in the request. > > > > > > > > Chris McCormack > > > > > > > > > > *** > > > This e-mail and its attachments are confidential > > > and are intended for the above named recipient > > > only. If this has come to you in error, please > > > notify the sender immediately and delete this > > > e-mail from your system. > > > You must take no action based on this, nor must > > > you copy or disclose it or any part of its > > contents > > > to any person or organisation. > > > Statements and opinions contained in this email > > may > > > not necessarily represent those of Littlewoods. > > > Please note that e-mail communications may be > > monitored. > > > The registered office of Littlewoods Limited and > > its > > > subsidiaries is 100 Old Hall Street, Liverpool, > > L70 1AB. > > > Registered number of Littlewoods Limited is > > 262152. > > > > > > > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > ___ > > > Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! > http://br.acesso.yahoo.com/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing ActionForm and MVC fields
Lee, even if i use different Actions i wil be still using BeanUtils and still suceptible to hacking. --- Lee Harrington <[EMAIL PROTECTED]> escreveu: > > In this case, i`m still suceptible to be > > hacked by javascript, because of the ActionForm > fields > > exposure. > > What about that??? > > Different actions. I'd reccomend a dispatch action > class...with > different methods depending on whether the buyer or > seller submitted. > That way, in the seller method, even if they did > hack the submit form > you action would not be doing anything with those > fields. > > Lee > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FRIDAY] Re: Exposing ActionForm and MVC fields
Well, not really, but disclaimers are interesting, aren't they? It's like the package of peanuts in airplanes that actually carry instructions: "Open package. Eat peanuts." On Fri, 15 Oct 2004 15:42:06 +0100, McCormack, Chris <[EMAIL PROTECTED]> wrote: > Nice rewording there, you in Law by any chance ;) > > -Original Message- > From: Hubert Rabago [mailto:[EMAIL PROTECTED] > Sent: 15 October 2004 15:33 > To: Struts Users Mailing List > Subject: Re: Exposing ActionForm and MVC fields > > > *** > > This e-mail and its attachments are not confidential > > and are intended for anyone who will believe what > > I've written without holding me liable. > > If this has come to you in error, please > > don't notify me at any given time and just delete this > > e-mail from your system. > > You must take no action that you will blame me for > > later, though if you want you can copy or disclose > > it or any part of its contents to any person or organisation. > > Statements and opinions contained in this email may > > not necessarily represent those people who > > pay me. Please note that e-mail > > communications may be monitored by those > > who have nothing better to do than read other people's e-mail. > > > > *** > > > This e-mail and its attachments are confidential > and are intended for the above named recipient > only. If this has come to you in error, please > notify the sender immediately and delete this > e-mail from your system. > You must take no action based on this, nor must > you copy or disclose it or any part of its contents > to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those of Littlewoods. > Please note that e-mail communications may be monitored. > The registered office of Littlewoods Limited and its > subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. > Registered number of Littlewoods Limited is 262152. > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing ActionForm and MVC fields
Do you other sugestion then Hubert? --- Hubert Rabago <[EMAIL PROTECTED]> escreveu: > Hmm... you'd have to check how BeanUtils works if > you do this. > BeanUtils will just copy properties without checking > for the declared > type, and in fact it can't check for the declared > type. Even if you > just pass an interface declaration, the instance > itself will expose > the properties and BeanUtils will still populate > them. > > > *** > > This e-mail and its attachments are not > confidential > > and are intended for anyone who will believe what > > I've written without holding me liable. > > If this has come to you in error, please > > don't notify me at any given time and just delete > this > > e-mail from your system. > > You must take no action that you will blame me for > > later, though if you want you can copy or disclose > > > it or any part of its contents to any person or > organisation. > > Statements and opinions contained in this email > may > > not necessarily represent those people who > > pay me. Please note that e-mail > > communications may be monitored by those > > who have nothing better to do than read other > people's e-mail. > > > > On Fri, 15 Oct 2004 15:24:21 +0100, McCormack, Chris > <[EMAIL PROTECTED]> wrote: > > Like this: > > > > MainDataObj implements ISeller, IBuyer > > > > Seller implements ISeller > > > > Buyer implements IBuyer > > > > Seller seller = (ISeller)mainDataObj; > > > > then add seller to the request and populate your > form from that for the Seller view and vice versa > for the Buyer view. > > > > Friday pub lunch may have tarred my brain but I > think that will work :) > > > > Chris > > > > > > > > -Original Message- > > From: Leandro Melo > [mailto:[EMAIL PROTECTED] > > Sent: 15 October 2004 14:49 > > To: Struts Users Mailing List > > Subject: RE: Exposing ActionForm and MVC fields > > > > Hi Chris, what do you mean by "interfaces to > filter" > > (sorry for the stupidness)??? > > Is it an ordinary Servlet filter?? > > If so, i remember once using a few filters but i > > coulnd`t get a reference to the request it self, > only > > to the context as a whole. Could you give an > example? > > > > --- "McCormack, Chris" > > <[EMAIL PROTECTED]> escreveu: > > > Look at using interfaces to filter the sensitive > > > data away from each user when putting the data > > > object in the request. > > > > > > Chris McCormack > > > > > > > *** > > This e-mail and its attachments are confidential > > and are intended for the above named recipient > > only. If this has come to you in error, please > > notify the sender immediately and delete this > > e-mail from your system. > > You must take no action based on this, nor must > > you copy or disclose it or any part of its > contents > > to any person or organisation. > > Statements and opinions contained in this email > may > > not necessarily represent those of Littlewoods. > > Please note that e-mail communications may be > monitored. > > The registered office of Littlewoods Limited and > its > > subsidiaries is 100 Old Hall Street, Liverpool, > L70 1AB. > > Registered number of Littlewoods Limited is > 262152. > > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exposing ActionForm and MVC fields
Nice rewording there, you in Law by any chance ;) -Original Message- From: Hubert Rabago [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 15:33 To: Struts Users Mailing List Subject: Re: Exposing ActionForm and MVC fields > *** > This e-mail and its attachments are not confidential > and are intended for anyone who will believe what > I've written without holding me liable. > If this has come to you in error, please > don't notify me at any given time and just delete this > e-mail from your system. > You must take no action that you will blame me for > later, though if you want you can copy or disclose > it or any part of its contents to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those people who > pay me. Please note that e-mail > communications may be monitored by those > who have nothing better to do than read other people's e-mail. > *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing ActionForm and MVC fields
Hmm... you'd have to check how BeanUtils works if you do this. BeanUtils will just copy properties without checking for the declared type, and in fact it can't check for the declared type. Even if you just pass an interface declaration, the instance itself will expose the properties and BeanUtils will still populate them. > *** > This e-mail and its attachments are not confidential > and are intended for anyone who will believe what > I've written without holding me liable. > If this has come to you in error, please > don't notify me at any given time and just delete this > e-mail from your system. > You must take no action that you will blame me for > later, though if you want you can copy or disclose > it or any part of its contents to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those people who > pay me. Please note that e-mail > communications may be monitored by those > who have nothing better to do than read other people's e-mail. > On Fri, 15 Oct 2004 15:24:21 +0100, McCormack, Chris <[EMAIL PROTECTED]> wrote: > Like this: > > MainDataObj implements ISeller, IBuyer > > Seller implements ISeller > > Buyer implements IBuyer > > Seller seller = (ISeller)mainDataObj; > > then add seller to the request and populate your form from that for the Seller view > and vice versa for the Buyer view. > > Friday pub lunch may have tarred my brain but I think that will work :) > > Chris > > > > -Original Message- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: 15 October 2004 14:49 > To: Struts Users Mailing List > Subject: RE: Exposing ActionForm and MVC fields > > Hi Chris, what do you mean by "interfaces to filter" > (sorry for the stupidness)??? > Is it an ordinary Servlet filter?? > If so, i remember once using a few filters but i > coulnd`t get a reference to the request it self, only > to the context as a whole. Could you give an example? > > --- "McCormack, Chris" > <[EMAIL PROTECTED]> escreveu: > > Look at using interfaces to filter the sensitive > > data away from each user when putting the data > > object in the request. > > > > Chris McCormack > > > > *** > This e-mail and its attachments are confidential > and are intended for the above named recipient > only. If this has come to you in error, please > notify the sender immediately and delete this > e-mail from your system. > You must take no action based on this, nor must > you copy or disclose it or any part of its contents > to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those of Littlewoods. > Please note that e-mail communications may be monitored. > The registered office of Littlewoods Limited and its > subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. > Registered number of Littlewoods Limited is 262152. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exposing ActionForm and MVC fields
Like this: MainDataObj implements ISeller, IBuyer Seller implements ISeller Buyer implements IBuyer Seller seller = (ISeller)mainDataObj; then add seller to the request and populate your form from that for the Seller view and vice versa for the Buyer view. Friday pub lunch may have tarred my brain but I think that will work :) Chris -Original Message- From: Leandro Melo [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 14:49 To: Struts Users Mailing List Subject: RE: Exposing ActionForm and MVC fields Hi Chris, what do you mean by "interfaces to filter" (sorry for the stupidness)??? Is it an ordinary Servlet filter?? If so, i remember once using a few filters but i coulnd`t get a reference to the request it self, only to the context as a whole. Could you give an example? --- "McCormack, Chris" <[EMAIL PROTECTED]> escreveu: > Look at using interfaces to filter the sensitive > data away from each user when putting the data > object in the request. > > Chris McCormack > *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing ActionForm and MVC fields
> In this case, i`m still suceptible to be > hacked by javascript, because of the ActionForm fields > exposure. > What about that??? Different actions. I'd reccomend a dispatch action class...with different methods depending on whether the buyer or seller submitted. That way, in the seller method, even if they did hack the submit form you action would not be doing anything with those fields. Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exposing ActionForm and MVC fields
Hi Chris, what do you mean by "interfaces to filter" (sorry for the stupidness)??? Is it an ordinary Servlet filter?? If so, i remember once using a few filters but i coulnd`t get a reference to the request it self, only to the context as a whole. Could you give an example? --- "McCormack, Chris" <[EMAIL PROTECTED]> escreveu: > Look at using interfaces to filter the sensitive > data away from each user when putting the data > object in the request. > > Chris McCormack > > -Original Message- > From: Leandro Melo > [mailto:[EMAIL PROTECTED] > Sent: 15 October 2004 13:53 > To: Struts Users Mailing List > Subject: RE: Exposing ActionForm and MVC fields > > > Hi guys, thanks for your opinions, it seems that > both > of you stick with approach 2. > > However, none of you mentioned that "exposing > ActionForm fields" problem. > > Suppose if build then 2 different pages (as you > adviced me). I guess my Action for this both pages > would still be the same, it will only send the > request > to 2 different pages depending the type of the > company. Usually, i set the jsps pages form`s inside > this Action (normally with BeanUtils), what will > force > me to give the correct names for the jsp form fields > (even if they are labels for the case the user > cannot > alter them). In this case, i`m still suceptible to > be > hacked by javascript, because of the ActionForm > fields > exposure. > What about that??? > > > > --- "McCormack, Chris" > <[EMAIL PROTECTED]> escreveu: > > +1 > > > > You could still create common elements to both > pages > > which will help maintain a look and feel and reuse > > existing code, look at using different tile > layouts > > for each user type but the elements in the page > are > > common jsp/tile definitions. > > If the spec for one user changes then you could > > simply just copy the tile fragment that was > changing > > to a new location and work on it, then change the > > tile definition for that user to point to the > > updated fragement. > > You would still maintain a majority of common code > > and in the long run even if both user views > totally > > change you can deal with it as and when the > changes > > happen by copying and altering each tile fragment > > that is changing and updating the tile definition > to > > point to the new fragment. > > > > Chris McCormack > > > > -Original Message- > > From: Freddy Villalba A. > > [mailto:[EMAIL PROTECTED] > > Sent: 15 October 2004 11:54 > > To: Struts Users Mailing List > > Subject: RE: Exposing ActionForm and MVC fields > > > > > > Hi, > > > > I'd go for approach #2. After all, they are > > different VIEWS of the same > > Model. > > > > I've faced this situation in a couple of projects > > before, and in both cases > > buyer's and seller's views differed in the long > run. > > The more complex your > > business rules / model gets, the higher is the > > chance for that happening. It > > may seem the right way to go at first (specially > if > > the differences are > > insignificant), but after a few meetings with the > > corporate managers, you'll > > realize it was not such a smart move after all! :P > > > > My humble oppinion, > > Freddy. > > > > -Mensaje original- > > De: Leandro Melo > [mailto:[EMAIL PROTECTED] > > Enviado el: viernes, 15 de octubre de 2004 3:30 > > Para: struts jakarta > > Asunto: Exposing ActionForm and MVC fields > > > > > > Hi, > > i'd like to hear some opinions. > > > > I got a b2b application. I'm facing a desing > > problem. > > This problems is associated basically to 2 themes: > > - MVC > > - Exposing AcfionForm fields. > > > > I got a page where the BUYER fills a form to buy > an > > specific item. The steps are very simple. > > > > 1 - He sends a request for a quotation. > > 2 - After the quotation, he sends a request for an > > order. > > > > The point is... > > When the SELLER goes to make the quotation he's > > supposed to see a very similar page to the one the > > BUYER filled the information. This is obvious as > the > > information is the same for both parts. So, should > i > > implement the page for the SELLER: > > > > ==>>>>>>> APPROACH 1 - using the same exact > page > >
RE: Exposing ActionForm and MVC fields
Look at using interfaces to filter the sensitive data away from each user when putting the data object in the request. Chris McCormack -Original Message- From: Leandro Melo [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 13:53 To: Struts Users Mailing List Subject: RE: Exposing ActionForm and MVC fields Hi guys, thanks for your opinions, it seems that both of you stick with approach 2. However, none of you mentioned that "exposing ActionForm fields" problem. Suppose if build then 2 different pages (as you adviced me). I guess my Action for this both pages would still be the same, it will only send the request to 2 different pages depending the type of the company. Usually, i set the jsps pages form`s inside this Action (normally with BeanUtils), what will force me to give the correct names for the jsp form fields (even if they are labels for the case the user cannot alter them). In this case, i`m still suceptible to be hacked by javascript, because of the ActionForm fields exposure. What about that??? --- "McCormack, Chris" <[EMAIL PROTECTED]> escreveu: > +1 > > You could still create common elements to both pages > which will help maintain a look and feel and reuse > existing code, look at using different tile layouts > for each user type but the elements in the page are > common jsp/tile definitions. > If the spec for one user changes then you could > simply just copy the tile fragment that was changing > to a new location and work on it, then change the > tile definition for that user to point to the > updated fragement. > You would still maintain a majority of common code > and in the long run even if both user views totally > change you can deal with it as and when the changes > happen by copying and altering each tile fragment > that is changing and updating the tile definition to > point to the new fragment. > > Chris McCormack > > -Original Message- > From: Freddy Villalba A. > [mailto:[EMAIL PROTECTED] > Sent: 15 October 2004 11:54 > To: Struts Users Mailing List > Subject: RE: Exposing ActionForm and MVC fields > > > Hi, > > I'd go for approach #2. After all, they are > different VIEWS of the same > Model. > > I've faced this situation in a couple of projects > before, and in both cases > buyer's and seller's views differed in the long run. > The more complex your > business rules / model gets, the higher is the > chance for that happening. It > may seem the right way to go at first (specially if > the differences are > insignificant), but after a few meetings with the > corporate managers, you'll > realize it was not such a smart move after all! :P > > My humble oppinion, > Freddy. > > -Mensaje original- > De: Leandro Melo [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 15 de octubre de 2004 3:30 > Para: struts jakarta > Asunto: Exposing ActionForm and MVC fields > > > Hi, > i'd like to hear some opinions. > > I got a b2b application. I'm facing a desing > problem. > This problems is associated basically to 2 themes: > - MVC > - Exposing AcfionForm fields. > > I got a page where the BUYER fills a form to buy an > specific item. The steps are very simple. > > 1 - He sends a request for a quotation. > 2 - After the quotation, he sends a request for an > order. > > The point is... > When the SELLER goes to make the quotation he's > supposed to see a very similar page to the one the > BUYER filled the information. This is obvious as the > information is the same for both parts. So, should i > implement the page for the SELLER: > > ==>>>>>>> APPROACH 1 - using the same exact page > as the BUYER for the SELLER. Then i'd make the > fields > the BUYER filled disabled (or just make them labels) > using some kind o scriptlet like this. > >.../> , > >where sellerVisibility would be something = >"disabled=true" > > This approach seems nice to but i'd say that it's > just > not that cool!!! It doesn't look nice from an MVC > point of view. I'll take the risk of having a lot of > this kind of scripts in pages as the times goes by. > I know that the Action (control layer) is actually > responsible for setting the "sellerVisibility", what > means that it's also not that bad from the MVC point > of view. > But any way, the major problem with this approah is > that i use BeanUtils to copy data from the > ActionForms > to the VOs and vice-versa. So even with the fields > disabled, i would take the risk of some smart guy > cheatting and setting via javascript the fields he's > no
RE: Exposing ActionForm and MVC fields
Hi guys, thanks for your opinions, it seems that both of you stick with approach 2. However, none of you mentioned that "exposing ActionForm fields" problem. Suppose if build then 2 different pages (as you adviced me). I guess my Action for this both pages would still be the same, it will only send the request to 2 different pages depending the type of the company. Usually, i set the jsps pages form`s inside this Action (normally with BeanUtils), what will force me to give the correct names for the jsp form fields (even if they are labels for the case the user cannot alter them). In this case, i`m still suceptible to be hacked by javascript, because of the ActionForm fields exposure. What about that??? --- "McCormack, Chris" <[EMAIL PROTECTED]> escreveu: > +1 > > You could still create common elements to both pages > which will help maintain a look and feel and reuse > existing code, look at using different tile layouts > for each user type but the elements in the page are > common jsp/tile definitions. > If the spec for one user changes then you could > simply just copy the tile fragment that was changing > to a new location and work on it, then change the > tile definition for that user to point to the > updated fragement. > You would still maintain a majority of common code > and in the long run even if both user views totally > change you can deal with it as and when the changes > happen by copying and altering each tile fragment > that is changing and updating the tile definition to > point to the new fragment. > > Chris McCormack > > -Original Message- > From: Freddy Villalba A. > [mailto:[EMAIL PROTECTED] > Sent: 15 October 2004 11:54 > To: Struts Users Mailing List > Subject: RE: Exposing ActionForm and MVC fields > > > Hi, > > I'd go for approach #2. After all, they are > different VIEWS of the same > Model. > > I've faced this situation in a couple of projects > before, and in both cases > buyer's and seller's views differed in the long run. > The more complex your > business rules / model gets, the higher is the > chance for that happening. It > may seem the right way to go at first (specially if > the differences are > insignificant), but after a few meetings with the > corporate managers, you'll > realize it was not such a smart move after all! :P > > My humble oppinion, > Freddy. > > -Mensaje original- > De: Leandro Melo [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 15 de octubre de 2004 3:30 > Para: struts jakarta > Asunto: Exposing ActionForm and MVC fields > > > Hi, > i'd like to hear some opinions. > > I got a b2b application. I'm facing a desing > problem. > This problems is associated basically to 2 themes: > - MVC > - Exposing AcfionForm fields. > > I got a page where the BUYER fills a form to buy an > specific item. The steps are very simple. > > 1 - He sends a request for a quotation. > 2 - After the quotation, he sends a request for an > order. > > The point is... > When the SELLER goes to make the quotation he's > supposed to see a very similar page to the one the > BUYER filled the information. This is obvious as the > information is the same for both parts. So, should i > implement the page for the SELLER: > > ==>>>>>>> APPROACH 1 - using the same exact page > as the BUYER for the SELLER. Then i'd make the > fields > the BUYER filled disabled (or just make them labels) > using some kind o scriptlet like this. > >.../> , > >where sellerVisibility would be something = >"disabled=true" > > This approach seems nice to but i'd say that it's > just > not that cool!!! It doesn't look nice from an MVC > point of view. I'll take the risk of having a lot of > this kind of scripts in pages as the times goes by. > I know that the Action (control layer) is actually > responsible for setting the "sellerVisibility", what > means that it's also not that bad from the MVC point > of view. > But any way, the major problem with this approah is > that i use BeanUtils to copy data from the > ActionForms > to the VOs and vice-versa. So even with the fields > disabled, i would take the risk of some smart guy > cheatting and setting via javascript the fields he's > not supposed to set. And as i copy the data with > BeanUtils, my data will be changed when it's not > supposed to do so. > > > >>>>> APPROACH 2 - just create another page > for the BUYER. This page would look exactly the same > for the BUYER and the SELLER, but
RE: Exposing ActionForm and MVC fields
+1 You could still create common elements to both pages which will help maintain a look and feel and reuse existing code, look at using different tile layouts for each user type but the elements in the page are common jsp/tile definitions. If the spec for one user changes then you could simply just copy the tile fragment that was changing to a new location and work on it, then change the tile definition for that user to point to the updated fragement. You would still maintain a majority of common code and in the long run even if both user views totally change you can deal with it as and when the changes happen by copying and altering each tile fragment that is changing and updating the tile definition to point to the new fragment. Chris McCormack -Original Message- From: Freddy Villalba A. [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 11:54 To: Struts Users Mailing List Subject: RE: Exposing ActionForm and MVC fields Hi, I'd go for approach #2. After all, they are different VIEWS of the same Model. I've faced this situation in a couple of projects before, and in both cases buyer's and seller's views differed in the long run. The more complex your business rules / model gets, the higher is the chance for that happening. It may seem the right way to go at first (specially if the differences are insignificant), but after a few meetings with the corporate managers, you'll realize it was not such a smart move after all! :P My humble oppinion, Freddy. -Mensaje original- De: Leandro Melo [mailto:[EMAIL PROTECTED] Enviado el: viernes, 15 de octubre de 2004 3:30 Para: struts jakarta Asunto: Exposing ActionForm and MVC fields Hi, i'd like to hear some opinions. I got a b2b application. I'm facing a desing problem. This problems is associated basically to 2 themes: - MVC - Exposing AcfionForm fields. I got a page where the BUYER fills a form to buy an specific item. The steps are very simple. 1 - He sends a request for a quotation. 2 - After the quotation, he sends a request for an order. The point is... When the SELLER goes to make the quotation he's supposed to see a very similar page to the one the BUYER filled the information. This is obvious as the information is the same for both parts. So, should i implement the page for the SELLER: ==>>>>>>> APPROACH 1 - using the same exact page as the BUYER for the SELLER. Then i'd make the fields the BUYER filled disabled (or just make them labels) using some kind o scriptlet like this. .../> , where sellerVisibility would be something = "disabled=true" This approach seems nice to but i'd say that it's just not that cool!!! It doesn't look nice from an MVC point of view. I'll take the risk of having a lot of this kind of scripts in pages as the times goes by. I know that the Action (control layer) is actually responsible for setting the "sellerVisibility", what means that it's also not that bad from the MVC point of view. But any way, the major problem with this approah is that i use BeanUtils to copy data from the ActionForms to the VOs and vice-versa. So even with the fields disabled, i would take the risk of some smart guy cheatting and setting via javascript the fields he's not supposed to set. And as i copy the data with BeanUtils, my data will be changed when it's not supposed to do so. >>>>> APPROACH 2 - just create another page for the BUYER. This page would look exactly the same for the BUYER and the SELLER, but they'll be different pages. This way, i can build this other very similar page without exposing my ActionForma attributes. This approach seems to me allright from the MVC point of view. But the problem of this approach is that i'd start building some kind of redundant and duplicated code. Any opinions... Leandro. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.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] *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be moni
RE: Exposing ActionForm and MVC fields
Hi, I'd go for approach #2. After all, they are different VIEWS of the same Model. I've faced this situation in a couple of projects before, and in both cases buyer's and seller's views differed in the long run. The more complex your business rules / model gets, the higher is the chance for that happening. It may seem the right way to go at first (specially if the differences are insignificant), but after a few meetings with the corporate managers, you'll realize it was not such a smart move after all! :P My humble oppinion, Freddy. -Mensaje original- De: Leandro Melo [mailto:[EMAIL PROTECTED] Enviado el: viernes, 15 de octubre de 2004 3:30 Para: struts jakarta Asunto: Exposing ActionForm and MVC fields Hi, i'd like to hear some opinions. I got a b2b application. I'm facing a desing problem. This problems is associated basically to 2 themes: - MVC - Exposing AcfionForm fields. I got a page where the BUYER fills a form to buy an specific item. The steps are very simple. 1 - He sends a request for a quotation. 2 - After the quotation, he sends a request for an order. The point is... When the SELLER goes to make the quotation he's supposed to see a very similar page to the one the BUYER filled the information. This is obvious as the information is the same for both parts. So, should i implement the page for the SELLER: ==>>> APPROACH 1 - using the same exact page as the BUYER for the SELLER. Then i'd make the fields the BUYER filled disabled (or just make them labels) using some kind o scriptlet like this. .../> , where sellerVisibility would be something = "disabled=true" This approach seems nice to but i'd say that it's just not that cool!!! It doesn't look nice from an MVC point of view. I'll take the risk of having a lot of this kind of scripts in pages as the times goes by. I know that the Action (control layer) is actually responsible for setting the "sellerVisibility", what means that it's also not that bad from the MVC point of view. But any way, the major problem with this approah is that i use BeanUtils to copy data from the ActionForms to the VOs and vice-versa. So even with the fields disabled, i would take the risk of some smart guy cheatting and setting via javascript the fields he's not supposed to set. And as i copy the data with BeanUtils, my data will be changed when it's not supposed to do so. > APPROACH 2 - just create another page for the BUYER. This page would look exactly the same for the BUYER and the SELLER, but they'll be different pages. This way, i can build this other very similar page without exposing my ActionForma attributes. This approach seems to me allright from the MVC point of view. But the problem of this approach is that i'd start building some kind of redundant and duplicated code. Any opinions... Leandro. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.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]
