I tried to send a reply early, but it got rejected because it was HTML
(oops).
I'm wondering if this is just another layer of configuration to
alleviate flawed designs. I always find that the web tier should be
accessible and only reveal setters for things it wants to consume. If I
want something protected I put it in a web-business-service tier where
it is better protected and I can control the injection and settings and
frameworks don't introduce dangerous automatic handling.
-bp
Martin Gilday wrote:
I've created an draft version and attached it to
https://issues.apache.org/struts/browse/WW-2274
It is a little bit messy at the moment and could be trimmed down a bit,
but from my basic tests it seems to be working.
Currently it only works on simple parameter names, so if you have a
parameter called 'one.two' then it will not match as you only have a
field named 'one'. A quick way around this might be to simply trim the
parameter name to the first '.'
----- Original message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Date: Wed, 24 Oct 2007 14:52:16 -0400
Subject: Re: [S2] Annotations (was Plugins gone wild!)
On 10/23/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
Well I am looking at the Parameter Filter Interceptor
(http://cwiki.apache.org/WW/parameter-filter-interceptor.html) which I
am proposing we complement by allowing the same thing with annotations.
Currently we have a wizard like section in one of our sites which we are
backing with Spring session scope beans. So the Struts2 Spring plugin
injects it. To allow this we have a setMySessionBeanName(), which is
public. So a user could call an action with a parameter
mySessionBeanName.forename and change that value. You can stop that
with the filter interceptor by defining mySessionBeanName as a blocked
parameter name, I would prefer to mark it @NotAParameter.
Why not @blocked and @allowed for the properties, and @defaultBlock
for the class?
-Ted.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
