You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Arron Bates <ar...@keyboardmonkey.com> on 2001/11/27 09:53:25 UTC
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Just a note on this subject....
You know that you can get absolutely sweet decoupling from everything
struts for your data model with the use of nesting objects?... And no
messy property copying!
I wanted to get a simple persistence mechanism running for my form
object, so I placed a little serialization logic into my action (Some
app servers need their session objects to serialize also, like iPlanet).
The struts action form wouldn't serialize for me so all I did was add an
extra nest level and serialized from there down leaving my entire
structure nothing but the data that I wanted. All the child objects
implement serializeable, extend nothing, and know nothing of struts.
This is all elegantly managed in the JSP's with the use of the
handy-dandy nesting extension. :)
That's my two cents.
If you want the code for what I just blabbed on about, mail me...
arron@keyboardmonkey.com
Arron.
(theKM*)
* I think, therefore, I nest ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron <ar...@keyboardmonkey.com>.
It's all here... the original nesting extension and the saving model I
just mentioned.
http://www.keyboardmonkey.com/downloads/struts/index.html
The main part of the action simply gets the data that held in a
hierarchy of objects from one method and serializes the result. It's in
the example "SavingMonkey" war file on the link above. It's all there.
Arron
Oleg V Alexeev wrote:
>Hello Arron,
>
>Tuesday, November 27, 2001, 11:53:25 AM, you wrote:
>
>AB> Just a note on this subject....
>
>AB> You know that you can get absolutely sweet decoupling from everything
>AB> struts for your data model with the use of nesting objects?... And no
>AB> messy property copying!
>
>AB> I wanted to get a simple persistence mechanism running for my form
>AB> object, so I placed a little serialization logic into my action (Some
>AB> app servers need their session objects to serialize also, like iPlanet).
>AB> The struts action form wouldn't serialize for me so all I did was add an
>AB> extra nest level and serialized from there down leaving my entire
>AB> structure nothing but the data that I wanted. All the child objects
>AB> implement serializeable, extend nothing, and know nothing of struts.
>
>AB> This is all elegantly managed in the JSP's with the use of the
>AB> handy-dandy nesting extension. :)
>
>AB> That's my two cents.
>AB> If you want the code for what I just blabbed on about, mail me...
>AB> arron@keyboardmonkey.com
>
>Can you post some samples to the list?
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
Tuesday, November 27, 2001, 11:53:25 AM, you wrote:
AB> Just a note on this subject....
AB> You know that you can get absolutely sweet decoupling from everything
AB> struts for your data model with the use of nesting objects?... And no
AB> messy property copying!
AB> I wanted to get a simple persistence mechanism running for my form
AB> object, so I placed a little serialization logic into my action (Some
AB> app servers need their session objects to serialize also, like iPlanet).
AB> The struts action form wouldn't serialize for me so all I did was add an
AB> extra nest level and serialized from there down leaving my entire
AB> structure nothing but the data that I wanted. All the child objects
AB> implement serializeable, extend nothing, and know nothing of struts.
AB> This is all elegantly managed in the JSP's with the use of the
AB> handy-dandy nesting extension. :)
AB> That's my two cents.
AB> If you want the code for what I just blabbed on about, mail me...
AB> arron@keyboardmonkey.com
Can you post some samples to the list?
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
It's true that I don't have the bandwidth right now to take a careful
look at your code, but I'm sure its quite good. It's linked both on my
site and the Struts resource page, and I'm sure people are getting value
from it.
My statement about nesting objects on ActionForm does hold. Strut's
autopopulate mechanism can be exploited if nested object have public
String or boolean properties that affect the system state. In Struts
1.0, you can do things like change the temporary directory for uploads
from a browser. We made this mistake on the original design of the
ActionForm, and I'm just trying to bring this to people's attention
whenever I can. I do not mean to discourage people from using nested
objects, only to use them wisely. Forewarned is forearmed.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4997
If your code provides an additional firewall, then a discussion of that
might be helpful, and draw more people into your package.
Arron wrote:
>
> That was kind of an ignorant comment. I don't know why you people
> resisting it so much.
> There is no danger in nesting objects at all.
>
> It is possible (however truly ugly) to do the same thing in out of the
> box struts. It's all about getting the JSP's to elegantly manage data
> structures you're most likely already using to some point. They release
> it to go free and make life terribly easier..
>
> Take a look at the code. They really do sit on struts. It relies on
> struts to do what it does. They only guide the struts tags to write out
> the write properties for things and fetch the right data. ALL the brains
> of it are a 38 line method.
> org.apache.struts.taglib.nested.NestedPropertyHelper.
> Please read it, I 'aint lyin'. :)
>
> At the risk of sounding cocky, the nested system introduces nothing but
> elegant data modelling and management.
>
> The rest (which takes more talent) I willingly leave to the rest of you
> boys. I just managed to finish something that I can't believe was left
> out. It really was 95% done for me.
>
> Stuts rocks, but this just lined it a little for the boys that have to
> cut it.
> It does cut developer time.
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
Ideas... Great.
I think that source code samples can be more useful than abstract
ideas in free style. Every developer in this list has his own work and
doing struts-related activity by his free time.
If you can help in this way to the community, please post code and
config samples to the list.
Wednesday, November 28, 2001, 5:22:45 PM, you wrote:
A> No code, just an idea after Ted provided a link to a thread of mails
A> that had to do with the original problem of getting at the struts system
A> objects.
A> But I'm lookin into it.
A> I'll get back to ya, but should be able to get a mock set-up running of
A> the idea itself...
A> ...then the debate can start as to the syntax of configuring it, and
A> when, should it be a singleton, ad-infinitum. :)
A> Arron
A> Oleg V Alexeev wrote:
>>Hello Arron,
>>
>>I think that it is intersting and flexible approach. Can you supply
>>samples for it or refactor existing code to support such ideas?
>>
>>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>>
>>AB> Not a special class, I'm talking about placing it into the process.
>>AB> Before the servlet updates the properties it checks for a security
>>AB> mapping. Based on the request and the security, it updates the
>>AB> properties. It would be more secure, and every property which is up to
>>AB> be set, can rest assured that it's safe. And that includes the
>>AB> properties that we "mean to expose" nested or otherwise.
>>
>>AB> All amounting to better security and an easier development path for the
>>AB> developers.
>>AB> I've had to use a decoupling through nested objects for an app that's in
>>AB> development. 100's of input fields. Writing proxy classes for it all.
>>AB> You have to be kidding.
>>
>>AB> Ted, there are some requirements out there where you *must* use nested
>>AB> objects.
>>AB> When is Struts going to *properly* support this!!??...
>>
>>
>>AB> Arron.
>>
>>AB> Ted Husted wrote:
>>
>>>>Personally, I have the feeling that it's better to encourage people to
>>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>>than invent a special class for people to learn.
>>>>
>>>>I actually believe that this is the approach that should have been used
>>>>in the first place, and in other places in the codebase. The
>>>>ActionServlet was placed there to provide access to certain properties,
>>>>and now the wrapper object defines exactly which properties those are.
>>>>An Encapsulate Class refactoring, if you will.
>>>>
>>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>>mean to expose.
>>>>
>>>>I think the important thing is to pound on the point that the ActionForm
>>>>is a firewall; it, and any objects it nests, are in the wild.
>>>>
>>>>Arron Bates wrote:
>>>>
>>>>> Yes, yes. Point made.
>>>>>That series of emails makes for some good bedside reading.
>>>>>
>>>>>I think that the solution that was arrived at is fine for protecting the
>>>>>struts system objects themselves.
>>>>>Is there anything happening to allow the developer to protect their own
>>>>>properties from this kind of arbitrary attack?
>>>>>
>>>>>Thought I had would be to configure a property modifier, or property
>>>>>mapping which yields other "security properties" which have to be
>>>>>checked before a property is set. ie: getMyProperty() property method
>>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>>while writing the view so you can't just pass the one key value pair to
>>>>>change a value, but a two key value pairs with the second value being a
>>>>>specific hashing or such. This would stop the casual hacking of any
>>>>>property via the URL. You could also then define a security property for
>>>>>all things struts within the ActionForm.
>>>>>
>>>>>The possibility then in extending this would be to define a security
>>>>>property to each property to be set, or a more simpler global security
>>>>>property for the entire request, and let the developer decide as to how
>>>>>fine grained the property setting security should be, if at all.
>>>>>
>>>>>Just a thought.
>>>>>
>>>>>Arron.
>>>>>
>>>>--
>>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>>
>>
>>
>>
>>AB> --
>>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
A> --
A> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
A> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
No code, just an idea after Ted provided a link to a thread of mails
that had to do with the original problem of getting at the struts system
objects.
But I'm lookin into it.
I'll get back to ya, but should be able to get a mock set-up running of
the idea itself...
...then the debate can start as to the syntax of configuring it, and
when, should it be a singleton, ad-infinitum. :)
Arron
Oleg V Alexeev wrote:
>Hello Arron,
>
>I think that it is intersting and flexible approach. Can you supply
>samples for it or refactor existing code to support such ideas?
>
>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>
>AB> Not a special class, I'm talking about placing it into the process.
>AB> Before the servlet updates the properties it checks for a security
>AB> mapping. Based on the request and the security, it updates the
>AB> properties. It would be more secure, and every property which is up to
>AB> be set, can rest assured that it's safe. And that includes the
>AB> properties that we "mean to expose" nested or otherwise.
>
>AB> All amounting to better security and an easier development path for the
>AB> developers.
>AB> I've had to use a decoupling through nested objects for an app that's in
>AB> development. 100's of input fields. Writing proxy classes for it all.
>AB> You have to be kidding.
>
>AB> Ted, there are some requirements out there where you *must* use nested
>AB> objects.
>AB> When is Struts going to *properly* support this!!??...
>
>
>AB> Arron.
>
>AB> Ted Husted wrote:
>
>>>Personally, I have the feeling that it's better to encourage people to
>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>than invent a special class for people to learn.
>>>
>>>I actually believe that this is the approach that should have been used
>>>in the first place, and in other places in the codebase. The
>>>ActionServlet was placed there to provide access to certain properties,
>>>and now the wrapper object defines exactly which properties those are.
>>>An Encapsulate Class refactoring, if you will.
>>>
>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>mean to expose.
>>>
>>>I think the important thing is to pound on the point that the ActionForm
>>>is a firewall; it, and any objects it nests, are in the wild.
>>>
>>>Arron Bates wrote:
>>>
>>>> Yes, yes. Point made.
>>>>That series of emails makes for some good bedside reading.
>>>>
>>>>I think that the solution that was arrived at is fine for protecting the
>>>>struts system objects themselves.
>>>>Is there anything happening to allow the developer to protect their own
>>>>properties from this kind of arbitrary attack?
>>>>
>>>>Thought I had would be to configure a property modifier, or property
>>>>mapping which yields other "security properties" which have to be
>>>>checked before a property is set. ie: getMyProperty() property method
>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>while writing the view so you can't just pass the one key value pair to
>>>>change a value, but a two key value pairs with the second value being a
>>>>specific hashing or such. This would stop the casual hacking of any
>>>>property via the URL. You could also then define a security property for
>>>>all things struts within the ActionForm.
>>>>
>>>>The possibility then in extending this would be to define a security
>>>>property to each property to be set, or a more simpler global security
>>>>property for the entire request, and let the developer decide as to how
>>>>fine grained the property setting security should be, if at all.
>>>>
>>>>Just a thought.
>>>>
>>>>Arron.
>>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>
>
>
>AB> --
>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
I think that it is intersting and flexible approach. Can you supply
samples for it or refactor existing code to support such ideas?
Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
AB> Not a special class, I'm talking about placing it into the process.
AB> Before the servlet updates the properties it checks for a security
AB> mapping. Based on the request and the security, it updates the
AB> properties. It would be more secure, and every property which is up to
AB> be set, can rest assured that it's safe. And that includes the
AB> properties that we "mean to expose" nested or otherwise.
AB> All amounting to better security and an easier development path for the
AB> developers.
AB> I've had to use a decoupling through nested objects for an app that's in
AB> development. 100's of input fields. Writing proxy classes for it all.
AB> You have to be kidding.
AB> Ted, there are some requirements out there where you *must* use nested
AB> objects.
AB> When is Struts going to *properly* support this!!??...
AB> Arron.
AB> Ted Husted wrote:
>>Personally, I have the feeling that it's better to encourage people to
>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>than invent a special class for people to learn.
>>
>>I actually believe that this is the approach that should have been used
>>in the first place, and in other places in the codebase. The
>>ActionServlet was placed there to provide access to certain properties,
>>and now the wrapper object defines exactly which properties those are.
>>An Encapsulate Class refactoring, if you will.
>>
>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>multiple ActionSerlvets in another thread. Instead of exposing the
>>ActionServlet, we should expose a JavaBean with only the properites we
>>mean to expose.
>>
>>I think the important thing is to pound on the point that the ActionForm
>>is a firewall; it, and any objects it nests, are in the wild.
>>
>>Arron Bates wrote:
>>
>>> Yes, yes. Point made.
>>>That series of emails makes for some good bedside reading.
>>>
>>>I think that the solution that was arrived at is fine for protecting the
>>>struts system objects themselves.
>>>Is there anything happening to allow the developer to protect their own
>>>properties from this kind of arbitrary attack?
>>>
>>>Thought I had would be to configure a property modifier, or property
>>>mapping which yields other "security properties" which have to be
>>>checked before a property is set. ie: getMyProperty() property method
>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>while writing the view so you can't just pass the one key value pair to
>>>change a value, but a two key value pairs with the second value being a
>>>specific hashing or such. This would stop the casual hacking of any
>>>property via the URL. You could also then define a security property for
>>>all things struts within the ActionForm.
>>>
>>>The possibility then in extending this would be to define a security
>>>property to each property to be set, or a more simpler global security
>>>property for the entire request, and let the developer decide as to how
>>>fine grained the property setting security should be, if at all.
>>>
>>>Just a thought.
>>>
>>>Arron.
>>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
AB> --
AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
Arron wrote:
> How does the current buffering mechanism do its thing for flat beans?...
> Is there a short answer without telling me to go read the code?... :)
The ActionForms ~are~ the buffering mechanism. That's one reason why
they are not an interface. They should not be tied directly to a model,
but serve as a pessimistic firewall betweeen the untrusted presentation
layer (HTTP/HTML), and the rest of your application, which can then be
more optimistic about the quality of data passed between components.
What's happened is that when we added the nesting feature (late in the
1.0 cycle), we opened a backdoor that can realize some of the same
problems caused when ActionForm was an interface. Someone can nest a
bean that is tied directly to the model, and a hostile user can make
unchecked system state changes.
But, so long as the beans you nest do not update the system state (as
the ActionServlet bean did), then there is nothing to worry about. A
value object, for example, would generally be OK, since they accept data
at one point, and then commit it at another. Between the accept and
commit points, you can validate the input. But the ActionServlet exposed
a direct setter, which is a bad thing on an ActionForm. So, we in
affect, we wrapped it in a value object, so unauthorized system state
changes could not be made.
Nesting beans on an ActionForm is a powerful tool, but with power comes
responsibility.
The one and only danger is nesting a bean that makes direct changes to
the system state via a public property which accepts a single String or
boolean parameter. Protected or private properties or properties with
complex signatures or types will not make it past the autopopulation
guantlet.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
> Arron.
>
> >
> >
> >Arron Bates wrote:
> >
> >>Not a special class, I'm talking about placing it into the process.
> >>Before the servlet updates the properties it checks for a security
> >>mapping. Based on the request and the security, it updates the
> >>properties. It would be more secure, and every property which is up to
> >>be set, can rest assured that it's safe. And that includes the
> >>properties that we "mean to expose" nested or otherwise.
> >>
> >>All amounting to better security and an easier development path for the
> >>developers.
> >>I've had to use a decoupling through nested objects for an app that's in
> >>development. 100's of input fields. Writing proxy classes for it all.
> >>You have to be kidding.
> >>
> >>Ted, there are some requirements out there where you *must* use nested
> >>objects.
> >>When is Struts going to *properly* support this!!??...
> >>
> >>Arron.
> >>
> >>Ted Husted wrote:
> >>
> >>>Personally, I have the feeling that it's better to encourage people to
> >>>define a proxy object, or wrapper, as was done with the ActionServlet,
> >>>than invent a special class for people to learn.
> >>>
> >>>I actually believe that this is the approach that should have been used
> >>>in the first place, and in other places in the codebase. The
> >>>ActionServlet was placed there to provide access to certain properties,
> >>>and now the wrapper object defines exactly which properties those are.
> >>>An Encapsulate Class refactoring, if you will.
> >>>
> >>>Meanwhile, I'm suggesting that we do the same sort of thing with
> >>>multiple ActionSerlvets in another thread. Instead of exposing the
> >>>ActionServlet, we should expose a JavaBean with only the properites we
> >>>mean to expose.
> >>>
> >>>I think the important thing is to pound on the point that the ActionForm
> >>>is a firewall; it, and any objects it nests, are in the wild.
> >>>
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
>
>
>This idea came up in the original thread, but no one stepped forward
>with any code.
>
It has my interest.
I'll first take a squizz at the target areas, generate a hack version,
look at the viability, and see what happens from there.
>The one and only time there is a problem is when the nested object makes
>a direct and immediate change to the internal system state. So long as
>the nested object is buffering the input, and can be validated before
>any change is committed, then it's a non-issue.
>
How does the current buffering mechanism do its thing for flat beans?...
Is there a short answer without telling me to go read the code?... :)
Arron.
>
>
>Arron Bates wrote:
>
>>Not a special class, I'm talking about placing it into the process.
>>Before the servlet updates the properties it checks for a security
>>mapping. Based on the request and the security, it updates the
>>properties. It would be more secure, and every property which is up to
>>be set, can rest assured that it's safe. And that includes the
>>properties that we "mean to expose" nested or otherwise.
>>
>>All amounting to better security and an easier development path for the
>>developers.
>>I've had to use a decoupling through nested objects for an app that's in
>>development. 100's of input fields. Writing proxy classes for it all.
>>You have to be kidding.
>>
>>Ted, there are some requirements out there where you *must* use nested
>>objects.
>>When is Struts going to *properly* support this!!??...
>>
>>Arron.
>>
>>Ted Husted wrote:
>>
>>>Personally, I have the feeling that it's better to encourage people to
>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>than invent a special class for people to learn.
>>>
>>>I actually believe that this is the approach that should have been used
>>>in the first place, and in other places in the codebase. The
>>>ActionServlet was placed there to provide access to certain properties,
>>>and now the wrapper object defines exactly which properties those are.
>>>An Encapsulate Class refactoring, if you will.
>>>
>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>mean to expose.
>>>
>>>I think the important thing is to pound on the point that the ActionForm
>>>is a firewall; it, and any objects it nests, are in the wild.
>>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
This idea came up in the original thread, but no one stepped forward
with any code.
The one and only time there is a problem is when the nested object makes
a direct and immediate change to the internal system state. So long as
the nested object is buffering the input, and can be validated before
any change is committed, then it's a non-issue.
Arron Bates wrote:
>
> Not a special class, I'm talking about placing it into the process.
> Before the servlet updates the properties it checks for a security
> mapping. Based on the request and the security, it updates the
> properties. It would be more secure, and every property which is up to
> be set, can rest assured that it's safe. And that includes the
> properties that we "mean to expose" nested or otherwise.
>
> All amounting to better security and an easier development path for the
> developers.
> I've had to use a decoupling through nested objects for an app that's in
> development. 100's of input fields. Writing proxy classes for it all.
> You have to be kidding.
>
> Ted, there are some requirements out there where you *must* use nested
> objects.
> When is Struts going to *properly* support this!!??...
>
> Arron.
>
> Ted Husted wrote:
>
> >Personally, I have the feeling that it's better to encourage people to
> >define a proxy object, or wrapper, as was done with the ActionServlet,
> >than invent a special class for people to learn.
> >
> >I actually believe that this is the approach that should have been used
> >in the first place, and in other places in the codebase. The
> >ActionServlet was placed there to provide access to certain properties,
> >and now the wrapper object defines exactly which properties those are.
> >An Encapsulate Class refactoring, if you will.
> >
> >Meanwhile, I'm suggesting that we do the same sort of thing with
> >multiple ActionSerlvets in another thread. Instead of exposing the
> >ActionServlet, we should expose a JavaBean with only the properites we
> >mean to expose.
> >
> >I think the important thing is to pound on the point that the ActionForm
> >is a firewall; it, and any objects it nests, are in the wild.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Not a special class, I'm talking about placing it into the process.
Before the servlet updates the properties it checks for a security
mapping. Based on the request and the security, it updates the
properties. It would be more secure, and every property which is up to
be set, can rest assured that it's safe. And that includes the
properties that we "mean to expose" nested or otherwise.
All amounting to better security and an easier development path for the
developers.
I've had to use a decoupling through nested objects for an app that's in
development. 100's of input fields. Writing proxy classes for it all.
You have to be kidding.
Ted, there are some requirements out there where you *must* use nested
objects.
When is Struts going to *properly* support this!!??...
Arron.
Ted Husted wrote:
>Personally, I have the feeling that it's better to encourage people to
>define a proxy object, or wrapper, as was done with the ActionServlet,
>than invent a special class for people to learn.
>
>I actually believe that this is the approach that should have been used
>in the first place, and in other places in the codebase. The
>ActionServlet was placed there to provide access to certain properties,
>and now the wrapper object defines exactly which properties those are.
>An Encapsulate Class refactoring, if you will.
>
>Meanwhile, I'm suggesting that we do the same sort of thing with
>multiple ActionSerlvets in another thread. Instead of exposing the
>ActionServlet, we should expose a JavaBean with only the properites we
>mean to expose.
>
>I think the important thing is to pound on the point that the ActionForm
>is a firewall; it, and any objects it nests, are in the wild.
>
>Arron Bates wrote:
>
>> Yes, yes. Point made.
>>That series of emails makes for some good bedside reading.
>>
>>I think that the solution that was arrived at is fine for protecting the
>>struts system objects themselves.
>>Is there anything happening to allow the developer to protect their own
>>properties from this kind of arbitrary attack?
>>
>>Thought I had would be to configure a property modifier, or property
>>mapping which yields other "security properties" which have to be
>>checked before a property is set. ie: getMyProperty() property method
>>uses a getMyPropertySecurity() to return a defined value which was set
>>while writing the view so you can't just pass the one key value pair to
>>change a value, but a two key value pairs with the second value being a
>>specific hashing or such. This would stop the casual hacking of any
>>property via the URL. You could also then define a security property for
>>all things struts within the ActionForm.
>>
>>The possibility then in extending this would be to define a security
>>property to each property to be set, or a more simpler global security
>>property for the entire request, and let the developer decide as to how
>>fine grained the property setting security should be, if at all.
>>
>>Just a thought.
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
Personally, I have the feeling that it's better to encourage people to
define a proxy object, or wrapper, as was done with the ActionServlet,
than invent a special class for people to learn.
I actually believe that this is the approach that should have been used
in the first place, and in other places in the codebase. The
ActionServlet was placed there to provide access to certain properties,
and now the wrapper object defines exactly which properties those are.
An Encapsulate Class refactoring, if you will.
Meanwhile, I'm suggesting that we do the same sort of thing with
multiple ActionSerlvets in another thread. Instead of exposing the
ActionServlet, we should expose a JavaBean with only the properites we
mean to expose.
I think the important thing is to pound on the point that the ActionForm
is a firewall; it, and any objects it nests, are in the wild.
Arron Bates wrote:
>
> Yes, yes. Point made.
> That series of emails makes for some good bedside reading.
>
> I think that the solution that was arrived at is fine for protecting the
> struts system objects themselves.
> Is there anything happening to allow the developer to protect their own
> properties from this kind of arbitrary attack?
>
> Thought I had would be to configure a property modifier, or property
> mapping which yields other "security properties" which have to be
> checked before a property is set. ie: getMyProperty() property method
> uses a getMyPropertySecurity() to return a defined value which was set
> while writing the view so you can't just pass the one key value pair to
> change a value, but a two key value pairs with the second value being a
> specific hashing or such. This would stop the casual hacking of any
> property via the URL. You could also then define a security property for
> all things struts within the ActionForm.
>
> The possibility then in extending this would be to define a security
> property to each property to be set, or a more simpler global security
> property for the entire request, and let the developer decide as to how
> fine grained the property setting security should be, if at all.
>
> Just a thought.
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Yes, yes. Point made.
That series of emails makes for some good bedside reading.
I think that the solution that was arrived at is fine for protecting the
struts system objects themselves.
Is there anything happening to allow the developer to protect their own
properties from this kind of arbitrary attack?
Thought I had would be to configure a property modifier, or property
mapping which yields other "security properties" which have to be
checked before a property is set. ie: getMyProperty() property method
uses a getMyPropertySecurity() to return a defined value which was set
while writing the view so you can't just pass the one key value pair to
change a value, but a two key value pairs with the second value being a
specific hashing or such. This would stop the casual hacking of any
property via the URL. You could also then define a security property for
all things struts within the ActionForm.
The possibility then in extending this would be to define a security
property to each property to be set, or a more simpler global security
property for the entire request, and let the developer decide as to how
fine grained the property setting security should be, if at all.
Just a thought.
Arron.
Ted Husted wrote:
>http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
>
>"So, someone could also call
>
>getServlet().setTempDir(whatever)
>
>with
>
>http://whatever.com/do/someAction?servlet.tempdir=whatever
>
>Hmmm."
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>
>Arron Bates wrote:
>
>>It doesn't even have to be a careful look at the code. It's not complex
>>in the least.
>>
>>I must be missing something with the "String or boolean properties that
>>affect the system state" thing.
>>
>>Do you mean what it is that I do with the example, where I have a string
>>property that represents a submit button that add objects to the tree
>>and another that can delete them?... If it isn't, can I get an example?...
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
"So, someone could also call
getServlet().setTempDir(whatever)
with
http://whatever.com/do/someAction?servlet.tempdir=whatever
Hmmm."
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Arron Bates wrote:
>
> It doesn't even have to be a careful look at the code. It's not complex
> in the least.
>
> I must be missing something with the "String or boolean properties that
> affect the system state" thing.
>
> Do you mean what it is that I do with the example, where I have a string
> property that represents a submit button that add objects to the tree
> and another that can delete them?... If it isn't, can I get an example?...
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron Bates <ar...@keyboardmonkey.com>.
It doesn't even have to be a careful look at the code. It's not complex
in the least.
I must be missing something with the "String or boolean properties that
affect the system state" thing.
Do you mean what it is that I do with the example, where I have a string
property that represents a submit button that add objects to the tree
and another that can delete them?... If it isn't, can I get an example?...
Arron.
Ted Husted wrote:
>It's true that I don't have the bandwidth right now to take a careful
>look at your code, but I'm sure its quite good. It's linked both on my
>site and the Struts resource page, and I'm sure people are getting value
>from it.
>
>My statement about nesting objects on ActionForm does hold. Strut's
>autopopulate mechanism can be exploited if nested object have public
>String or boolean properties that affect the system state. In Struts
>1.0, you can do things like change the temporary directory for uploads
>from a browser. We made this mistake on the original design of the
>ActionForm, and I'm just trying to bring this to people's attention
>whenever I can. I do not mean to discourage people from using nested
>objects, only to use them wisely. Forewarned is forearmed.
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4997
>
>If your code provides an additional firewall, then a discussion of that
>might be helpful, and draw more people into your package.
>
>Arron wrote:
>
>>That was kind of an ignorant comment. I don't know why you people
>>resisting it so much.
>>There is no danger in nesting objects at all.
>>
>>It is possible (however truly ugly) to do the same thing in out of the
>>box struts. It's all about getting the JSP's to elegantly manage data
>>structures you're most likely already using to some point. They release
>>it to go free and make life terribly easier..
>>
>>Take a look at the code. They really do sit on struts. It relies on
>>struts to do what it does. They only guide the struts tags to write out
>>the write properties for things and fetch the right data. ALL the brains
>>of it are a 38 line method.
>>org.apache.struts.taglib.nested.NestedPropertyHelper.
>>Please read it, I 'aint lyin'. :)
>>
>>At the risk of sounding cocky, the nested system introduces nothing but
>>elegant data modelling and management.
>>
>>The rest (which takes more talent) I willingly leave to the rest of you
>>boys. I just managed to finish something that I can't believe was left
>>out. It really was 95% done for me.
>>
>>Stuts rocks, but this just lined it a little for the boys that have to
>>cut it.
>>It does cut developer time.
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Arron wrote:
> That was kind of an ignorant comment. I don't know why you people
> resisting it so much.
> There is no danger in nesting objects at all.
>
> It is possible (however truly ugly) to do the same thing in out of the
> box struts. It's all about getting the JSP's to elegantly manage data
> structures you're most likely already using to some point. They
> release it to go free and make life terribly easier..
>
> Take a look at the code. They really do sit on struts. It relies on
> struts to do what it does. They only guide the struts tags to write
> out the write properties for things and fetch the right data. ALL the
> brains of it are a 38 line method.
> org.apache.struts.taglib.nested.NestedPropertyHelper.
> Please read it, I 'aint lyin'. :)
>
> At the risk of sounding cocky, the nested system introduces nothing
> but elegant data modelling and management.
>
> The rest (which takes more talent) I willingly leave to the rest of
> you boys. I just managed to finish something that I can't believe was
> left out. It really was 95% done for me.
>
> Stuts rocks, but this just lined it a little for the boys that have to
> cut it.
> It does cut developer time.
>
>
> Arron.
>
>
> Ted Husted wrote:
>
>> The one thing to watch with nested objects is that they don't expose
>> anything that should not be exposed.
>> One thing we plugged in the imminent 1.01 release candidate is "nesting"
>> ActionServlet on the ActionForm. This let you do silly things like set
>> the temporary directory for uploads from a browser. It now uses a
>> ActionServletWrapper to only expose the non-String properties which are
>> absolutely needed (a proxy object).
>>
>> So it's important that any object nested on an ActionForm not make state
>> changes without validation, at least through String and boolean
>> properties.
>> -- Ted Husted, Husted dot Com, Fairport NY USA.
>> -- Custom Software ~ Technical Services.
>> -- Tel +1 716 737-3463
>> -- http://www.husted.com/struts/
>>
>>
>> Arron Bates wrote:
>>
>>> Just a note on this subject....
>>>
>>> You know that you can get absolutely sweet decoupling from everything
>>> struts for your data model with the use of nesting objects?... And no
>>> messy property copying!
>>>
>>> I wanted to get a simple persistence mechanism running for my form
>>> object, so I placed a little serialization logic into my action (Some
>>> app servers need their session objects to serialize also, like
>>> iPlanet).
>>> The struts action form wouldn't serialize for me so all I did was
>>> add an
>>> extra nest level and serialized from there down leaving my entire
>>> structure nothing but the data that I wanted. All the child objects
>>> implement serializeable, extend nothing, and know nothing of struts.
>>>
>>> This is all elegantly managed in the JSP's with the use of the
>>> handy-dandy nesting extension. :)
>>>
>>> That's my two cents.
>>> If you want the code for what I just blabbed on about, mail me...
>>> arron@keyboardmonkey.com
>>>
>>> Arron.
>>> (theKM*)
>>> * I think, therefore, I nest ;)
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron <ar...@keyboardmonkey.com>.
That was kind of an ignorant comment. I don't know why you people
resisting it so much.
There is no danger in nesting objects at all.
It is possible (however truly ugly) to do the same thing in out of the
box struts. It's all about getting the JSP's to elegantly manage data
structures you're most likely already using to some point. They release
it to go free and make life terribly easier..
Take a look at the code. They really do sit on struts. It relies on
struts to do what it does. They only guide the struts tags to write out
the write properties for things and fetch the right data. ALL the brains
of it are a 38 line method.
org.apache.struts.taglib.nested.NestedPropertyHelper.
Please read it, I 'aint lyin'. :)
At the risk of sounding cocky, the nested system introduces nothing but
elegant data modelling and management.
The rest (which takes more talent) I willingly leave to the rest of you
boys. I just managed to finish something that I can't believe was left
out. It really was 95% done for me.
Stuts rocks, but this just lined it a little for the boys that have to
cut it.
It does cut developer time.
Arron.
Ted Husted wrote:
>The one thing to watch with nested objects is that they don't expose
>anything that should not be exposed.
>
>One thing we plugged in the imminent 1.01 release candidate is "nesting"
>ActionServlet on the ActionForm. This let you do silly things like set
>the temporary directory for uploads from a browser. It now uses a
>ActionServletWrapper to only expose the non-String properties which are
>absolutely needed (a proxy object).
>
>So it's important that any object nested on an ActionForm not make state
>changes without validation, at least through String and boolean
>properties.
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>
>Arron Bates wrote:
>
>>Just a note on this subject....
>>
>>You know that you can get absolutely sweet decoupling from everything
>>struts for your data model with the use of nesting objects?... And no
>>messy property copying!
>>
>>I wanted to get a simple persistence mechanism running for my form
>>object, so I placed a little serialization logic into my action (Some
>>app servers need their session objects to serialize also, like iPlanet).
>>The struts action form wouldn't serialize for me so all I did was add an
>>extra nest level and serialized from there down leaving my entire
>>structure nothing but the data that I wanted. All the child objects
>>implement serializeable, extend nothing, and know nothing of struts.
>>
>>This is all elegantly managed in the JSP's with the use of the
>>handy-dandy nesting extension. :)
>>
>>That's my two cents.
>>If you want the code for what I just blabbed on about, mail me...
>>arron@keyboardmonkey.com
>>
>>Arron.
>>(theKM*)
>>* I think, therefore, I nest ;)
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
The one thing to watch with nested objects is that they don't expose
anything that should not be exposed.
One thing we plugged in the imminent 1.01 release candidate is "nesting"
ActionServlet on the ActionForm. This let you do silly things like set
the temporary directory for uploads from a browser. It now uses a
ActionServletWrapper to only expose the non-String properties which are
absolutely needed (a proxy object).
So it's important that any object nested on an ActionForm not make state
changes without validation, at least through String and boolean
properties.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Arron Bates wrote:
>
> Just a note on this subject....
>
> You know that you can get absolutely sweet decoupling from everything
> struts for your data model with the use of nesting objects?... And no
> messy property copying!
>
> I wanted to get a simple persistence mechanism running for my form
> object, so I placed a little serialization logic into my action (Some
> app servers need their session objects to serialize also, like iPlanet).
> The struts action form wouldn't serialize for me so all I did was add an
> extra nest level and serialized from there down leaving my entire
> structure nothing but the data that I wanted. All the child objects
> implement serializeable, extend nothing, and know nothing of struts.
>
> This is all elegantly managed in the JSP's with the use of the
> handy-dandy nesting extension. :)
>
> That's my two cents.
> If you want the code for what I just blabbed on about, mail me...
> arron@keyboardmonkey.com
>
> Arron.
> (theKM*)
> * I think, therefore, I nest ;)
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>