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 arb
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 p
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 t
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 befor
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
>
>
>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 ne
cc:
11/27/01 08:45 Subject: Re: Extensibility of struts &
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 mod
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 28, 2001 3:29 PM
To: Struts Developers List
Subject: Re: Extensibility of struts & Property Security
Please use the standard java security mechanism, rather than trying to
invent a new one. The standard mecha
>
>"Lacerda,
>
> Wellington (AFIS)"To: "'[EMAIL PROTECTED]'"
><[EM
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 up
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 t
12 matches
Mail list logo
