Re[2]: Extensibility of struts & Property Security

[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[2]: Extensibility of struts & Property Security

[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

[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>