Please use the standard java security mechanism, rather than trying to
invent a new one. The standard mechanism is very general, and allows very
fast checks when security is turned off, and conversely, allows very
fine-grained security checks to be made. I have implemented this in a
web-model and it works quite well. Send me email if you want more
information on using it, preferably after you read the java documentation
(look at JAAS).
Bill Wallace
(716) 214-8872
Fax: (716) 295-4718
Element K
'the knowledge catalyst'
www.elementk.com
Arron Bates
<arron@keyboardm To: Struts Developers List
<[EMAIL PROTECTED]>
onkey.com> cc:
11/27/01 08:45 Subject: Re: Extensibility of struts &
Property Security
PM
Please respond
to "Struts
Developers List"
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: <
mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
