You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2007/12/06 08:08:14 UTC
S1/2: Data integrity and security
I've been emailing the authors of HDIV offline for some quite time. I take a
fond interest in data integrity and security, and believe their project is a
great benefit to Struts. The problem, of course, exists that S1 and S2 are
so radical in architecture that separate deliverables are required.
I think a framework SPI should be provided so that library implementors can
scramble form data (e.g., hidden form field values) and provide whatever
encryption necessary. The goal would be for this SPI to be honored in both
Struts 1.4 and latest Struts 2.x. This would be the start of a shared
library between Struts versions.
These are the current known extension points that the SPI would be invoked
for:
1. Form start point
2. Form end point
3. Link or form's action
4. Form's Parameters name
5. FoParameter's values
Where is the right place to whiteboard this idea? Email or MoinMoin? And is
anyone else interested in helping?
Paul
Re: S1/2: Data integrity and security
Posted by Paul Benedict <pb...@apache.org>.
Makes sense. But I wouldn't want to fork the project because I am not a
security expert. I couldn't maintain it well even though I want to integrate
it. Also, I don't know if HDIV has aspirations outside of Struts which would
make an SPI much more palatable.
What do you think about sharing the code between struts projects? As a jar
that would be used natively within the core?
Paul
On Dec 6, 2007 11:34 AM, Matt Raible <mr...@gmail.com> wrote:
> HDIV seems to solve a problem that most web application developers
> don't know they have. By "natively", I mean it's part of the core and
> you can't make your application less secure by ripping it out. It is
> Apache licensed after all.
>
> If rolling it into the core isn't an option, it would be nice if it
> was easier to integrate. Instead of requiring new tag libraries, it'd
> be nice if tag libraries (and Velocity/FreeMarker macros) were "HDIV
> aware". If an HDIV JAR/Plugin is on the classpath - use it.
>
> Matt
>
> On Dec 6, 2007, at 9:22 AM, Paul Benedict wrote:
>
> > Matt, I want to use HDIV natively in Struts 1 too -- which is why I
> > was
> > hoping for an SPI interface which anyone can provide for an
> > implementation.
> > What do you have in mind with "native" integration? And is your
> > idea of
> > integration also against an SPI?
> >
> > Paul
> >
> > On Dec 6, 2007 10:18 AM, Matt Raible <mr...@gmail.com> wrote:
> >
> >> What about integrating HDIV natively so Struts is as secure as it can
> >> possibly be?
> >>
> >> Matt
> >>
> >> On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote:
> >>
> >>> I've been emailing the authors of HDIV offline for some quite time.
> >>> I take a
> >>> fond interest in data integrity and security, and believe their
> >>> project is a
> >>> great benefit to Struts. The problem, of course, exists that S1 and
> >>> S2 are
> >>> so radical in architecture that separate deliverables are required.
> >>>
> >>> I think a framework SPI should be provided so that library
> >>> implementors can
> >>> scramble form data (e.g., hidden form field values) and provide
> >>> whatever
> >>> encryption necessary. The goal would be for this SPI to be honored
> >>> in both
> >>> Struts 1.4 and latest Struts 2.x. This would be the start of a
> >>> shared
> >>> library between Struts versions.
> >>>
> >>> These are the current known extension points that the SPI would be
> >>> invoked
> >>> for:
> >>>
> >>> 1. Form start point
> >>> 2. Form end point
> >>> 3. Link or form's action
> >>> 4. Form's Parameters name
> >>> 5. FoParameter's values
> >>>
> >>> Where is the right place to whiteboard this idea? Email or
> >>> MoinMoin? And is
> >>> anyone else interested in helping?
> >>>
> >>> Paul
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: S1/2: Data integrity and security
Posted by Ted Husted <hu...@apache.org>.
On Dec 6, 2007 10:59 PM, Paul Benedict <pb...@apache.org> wrote:
> I think we should document this question on the wiki and whiteboard this
> idea. The makers of HDIV will be able to contribute answers there too.
HDIV is being distributed via SourceForge, and SourceForge offers a
wiki now too.
If the notion is to have a multi-framework interface that would work
with S1, S2, Tapestry, Wicket, and so forth, perhaps HDIV should
activate their wiki, and we could invite people from those groups to
chime in.
It's also something that we could bring up on our favorite "Rebel
Looking for a Cause", the Java Web Alignment Group :)
* http://tech.groups.yahoo.com/group/java_web_alignment/
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: S1/2: Data integrity and security
Posted by Paul Benedict <pb...@apache.org>.
On Dec 6, 2007 1:27 PM, Martin Cooper <ma...@apache.org> wrote:
>
> Which security package(s) would you want to work with in addition to HDIV?
> I
> firmly believe that you need at least two candidates in order to
> successfully design an SPI. Otherwise you run a very high risk of
> designing
> an SPI that can really only be successfully used by the one candidate you
> designed it around.
>
This is an excellent point. I have not considered this point of view before.
I agree with your reasoning.
>
> A couple of other questions:
>
> * How does HDIV's editable content validation interact with the validation
> mechanisms that we already have built into Struts? Is someone using HDIV
> with Struts going to be writing their validations using HDIV's format,
> Commons Validator's format, or both?
>
I think we should document this question on the wiki and whiteboard this
idea. The makers of HDIV will be able to contribute answers there too.
>
> * How much of the functionality of HDIV is only available for people using
> JSP with tag libraries? If I'm using Velocity, or not using server-side
> presentation at all, how much of HDIV do I lose?
>
>
Ditto.
Paul
Re: S1/2: Data integrity and security
Posted by Martin Cooper <ma...@apache.org>.
On Dec 6, 2007 10:22 AM, Paul Benedict <pb...@apache.org> wrote:
> On Dec 6, 2007 12:17 PM, Ted Husted <hu...@apache.org> wrote:
>
> > Although I have no clue what SPI means, I do see the web page mentions
> > Struts by name, and says that it can be added to applications
> > transparently.
>
>
> SPI is Service Provider Interface. The Framework would be built around an
> interface, and then Struts would be configured to use an SPI
> implementation.
Which security package(s) would you want to work with in addition to HDIV? I
firmly believe that you need at least two candidates in order to
successfully design an SPI. Otherwise you run a very high risk of designing
an SPI that can really only be successfully used by the one candidate you
designed it around.
A couple of other questions:
* How does HDIV's editable content validation interact with the validation
mechanisms that we already have built into Struts? Is someone using HDIV
with Struts going to be writing their validations using HDIV's format,
Commons Validator's format, or both?
* How much of the functionality of HDIV is only available for people using
JSP with tag libraries? If I'm using Velocity, or not using server-side
presentation at all, how much of HDIV do I lose?
>
> The JDK has many SPI packages.
>
>
> > The vast majority of web applications run inside a firewall and are
> > used by a handful of trusted employees. There are many cases where
> > Klingon-grade security may not always trump day-to-day performance.
>
>
> LOL
>
>
> > On the Struts 1 security front, there are also projects like the
> > Struts SSL Extension which could be subsumed into the core.
>
>
> I am not strongly in favor of belonging to the core. I think the feature
> should be optional, but I wouldn't also object if it was put of the core
> with the option to turn on/off.
>
> The developers of HDIV said their programming model would be extremely
> simplified if they could have an SPI that targets both versions of Struts.
> I
> agree and I think it also opens the door to other people doing other kinds
> of implementations.
I'm not really convinced. Given that HDIV already supports Struts 1, Struts
2, Spring MVC and JSTL, with JSF coming, it seems to me that to really
simplify what they're doing, they would need all of those frameworks to
support a common SPI. Providing one just for S1 and S2 still leaves them
with only one fewer frameworks to deal with.
Now, working to provide a common SPI across *all* of those frameworks -
*that* would be an interesting exercise...
--
Martin Cooper
>
> Paul
>
Re: S1/2: Data integrity and security
Posted by Paul Benedict <pb...@apache.org>.
On Dec 6, 2007 12:17 PM, Ted Husted <hu...@apache.org> wrote:
> Although I have no clue what SPI means, I do see the web page mentions
> Struts by name, and says that it can be added to applications
> transparently.
SPI is Service Provider Interface. The Framework would be built around an
interface, and then Struts would be configured to use an SPI implementation.
The JDK has many SPI packages.
> The vast majority of web applications run inside a firewall and are
> used by a handful of trusted employees. There are many cases where
> Klingon-grade security may not always trump day-to-day performance.
LOL
> On the Struts 1 security front, there are also projects like the
> Struts SSL Extension which could be subsumed into the core.
I am not strongly in favor of belonging to the core. I think the feature
should be optional, but I wouldn't also object if it was put of the core
with the option to turn on/off.
The developers of HDIV said their programming model would be extremely
simplified if they could have an SPI that targets both versions of Struts. I
agree and I think it also opens the door to other people doing other kinds
of implementations.
Paul
Re: S1/2: Data integrity and security
Posted by Ted Husted <hu...@apache.org>.
It's unusual that a feature such as this comes without penality. If
HDIV were native, what would be the performance cost? Complexity cost?
Although I have no clue what SPI means, I do see the web page mentions
Struts by name, and says that it can be added to applications
transparently.
What if we were to start by adding HDIV to our example applications
and posting the result in the sandbox. This would give us an
opportunity to identify any pain points, as well as compare the
performance impact.
The vast majority of web applications run inside a firewall and are
used by a handful of trusted employees. There are many cases where
Klingon-grade security may not always trump day-to-day performance.
On the Struts 1 security front, there are also projects like the
Struts SSL Extension which could be subsumed into the core.
-Ted.
On Dec 6, 2007 12:34 PM, Matt Raible <mr...@gmail.com> wrote:
> HDIV seems to solve a problem that most web application developers
> don't know they have. By "natively", I mean it's part of the core and
> you can't make your application less secure by ripping it out. It is
> Apache licensed after all.
>
> If rolling it into the core isn't an option, it would be nice if it
> was easier to integrate. Instead of requiring new tag libraries, it'd
> be nice if tag libraries (and Velocity/FreeMarker macros) were "HDIV
> aware". If an HDIV JAR/Plugin is on the classpath - use it.
>
> Matt
>
>
> On Dec 6, 2007, at 9:22 AM, Paul Benedict wrote:
>
> > Matt, I want to use HDIV natively in Struts 1 too -- which is why I
> > was
> > hoping for an SPI interface which anyone can provide for an
> > implementation.
> > What do you have in mind with "native" integration? And is your
> > idea of
> > integration also against an SPI?
> >
> > Paul
> >
> > On Dec 6, 2007 10:18 AM, Matt Raible <mr...@gmail.com> wrote:
> >
> >> What about integrating HDIV natively so Struts is as secure as it can
> >> possibly be?
> >>
> >> Matt
> >>
> >> On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote:
> >>
> >>> I've been emailing the authors of HDIV offline for some quite time.
> >>> I take a
> >>> fond interest in data integrity and security, and believe their
> >>> project is a
> >>> great benefit to Struts. The problem, of course, exists that S1 and
> >>> S2 are
> >>> so radical in architecture that separate deliverables are required.
> >>>
> >>> I think a framework SPI should be provided so that library
> >>> implementors can
> >>> scramble form data (e.g., hidden form field values) and provide
> >>> whatever
> >>> encryption necessary. The goal would be for this SPI to be honored
> >>> in both
> >>> Struts 1.4 and latest Struts 2.x. This would be the start of a
> >>> shared
> >>> library between Struts versions.
> >>>
> >>> These are the current known extension points that the SPI would be
> >>> invoked
> >>> for:
> >>>
> >>> 1. Form start point
> >>> 2. Form end point
> >>> 3. Link or form's action
> >>> 4. Form's Parameters name
> >>> 5. FoParameter's values
> >>>
> >>> Where is the right place to whiteboard this idea? Email or
> >>> MoinMoin? And is
> >>> anyone else interested in helping?
> >>>
> >>> Paul
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted
* <http://www.StrutsMentor.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: S1/2: Data integrity and security
Posted by Matt Raible <mr...@gmail.com>.
HDIV seems to solve a problem that most web application developers
don't know they have. By "natively", I mean it's part of the core and
you can't make your application less secure by ripping it out. It is
Apache licensed after all.
If rolling it into the core isn't an option, it would be nice if it
was easier to integrate. Instead of requiring new tag libraries, it'd
be nice if tag libraries (and Velocity/FreeMarker macros) were "HDIV
aware". If an HDIV JAR/Plugin is on the classpath - use it.
Matt
On Dec 6, 2007, at 9:22 AM, Paul Benedict wrote:
> Matt, I want to use HDIV natively in Struts 1 too -- which is why I
> was
> hoping for an SPI interface which anyone can provide for an
> implementation.
> What do you have in mind with "native" integration? And is your
> idea of
> integration also against an SPI?
>
> Paul
>
> On Dec 6, 2007 10:18 AM, Matt Raible <mr...@gmail.com> wrote:
>
>> What about integrating HDIV natively so Struts is as secure as it can
>> possibly be?
>>
>> Matt
>>
>> On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote:
>>
>>> I've been emailing the authors of HDIV offline for some quite time.
>>> I take a
>>> fond interest in data integrity and security, and believe their
>>> project is a
>>> great benefit to Struts. The problem, of course, exists that S1 and
>>> S2 are
>>> so radical in architecture that separate deliverables are required.
>>>
>>> I think a framework SPI should be provided so that library
>>> implementors can
>>> scramble form data (e.g., hidden form field values) and provide
>>> whatever
>>> encryption necessary. The goal would be for this SPI to be honored
>>> in both
>>> Struts 1.4 and latest Struts 2.x. This would be the start of a
>>> shared
>>> library between Struts versions.
>>>
>>> These are the current known extension points that the SPI would be
>>> invoked
>>> for:
>>>
>>> 1. Form start point
>>> 2. Form end point
>>> 3. Link or form's action
>>> 4. Form's Parameters name
>>> 5. FoParameter's values
>>>
>>> Where is the right place to whiteboard this idea? Email or
>>> MoinMoin? And is
>>> anyone else interested in helping?
>>>
>>> Paul
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: S1/2: Data integrity and security
Posted by Paul Benedict <pb...@apache.org>.
Matt, I want to use HDIV natively in Struts 1 too -- which is why I was
hoping for an SPI interface which anyone can provide for an implementation.
What do you have in mind with "native" integration? And is your idea of
integration also against an SPI?
Paul
On Dec 6, 2007 10:18 AM, Matt Raible <mr...@gmail.com> wrote:
> What about integrating HDIV natively so Struts is as secure as it can
> possibly be?
>
> Matt
>
> On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote:
>
> > I've been emailing the authors of HDIV offline for some quite time.
> > I take a
> > fond interest in data integrity and security, and believe their
> > project is a
> > great benefit to Struts. The problem, of course, exists that S1 and
> > S2 are
> > so radical in architecture that separate deliverables are required.
> >
> > I think a framework SPI should be provided so that library
> > implementors can
> > scramble form data (e.g., hidden form field values) and provide
> > whatever
> > encryption necessary. The goal would be for this SPI to be honored
> > in both
> > Struts 1.4 and latest Struts 2.x. This would be the start of a shared
> > library between Struts versions.
> >
> > These are the current known extension points that the SPI would be
> > invoked
> > for:
> >
> > 1. Form start point
> > 2. Form end point
> > 3. Link or form's action
> > 4. Form's Parameters name
> > 5. FoParameter's values
> >
> > Where is the right place to whiteboard this idea? Email or
> > MoinMoin? And is
> > anyone else interested in helping?
> >
> > Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: S1/2: Data integrity and security
Posted by Matt Raible <mr...@gmail.com>.
What about integrating HDIV natively so Struts is as secure as it can
possibly be?
Matt
On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote:
> I've been emailing the authors of HDIV offline for some quite time.
> I take a
> fond interest in data integrity and security, and believe their
> project is a
> great benefit to Struts. The problem, of course, exists that S1 and
> S2 are
> so radical in architecture that separate deliverables are required.
>
> I think a framework SPI should be provided so that library
> implementors can
> scramble form data (e.g., hidden form field values) and provide
> whatever
> encryption necessary. The goal would be for this SPI to be honored
> in both
> Struts 1.4 and latest Struts 2.x. This would be the start of a shared
> library between Struts versions.
>
> These are the current known extension points that the SPI would be
> invoked
> for:
>
> 1. Form start point
> 2. Form end point
> 3. Link or form's action
> 4. Form's Parameters name
> 5. FoParameter's values
>
> Where is the right place to whiteboard this idea? Email or
> MoinMoin? And is
> anyone else interested in helping?
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org