> > That way is ok. But it doesn't really *enforce* security. It will just
> > give user that are already aware of the security hazards an easy way of
> > securing their system.
> > But IMHO that's the not the best way. We should enforce security as
> > default and only explicitly remove it for certain cases. But as you
> > said: it's really hard to come up with an over-all-solution that also
> > holds the balance between additional work and additional security.
>
> Making it optional would be ok, but somehow this seems to beg a larger
> architectural (almost philosophical) question: to what extent can Cocoon
> enforce security of any kind? At some point any developer using any tool to
> build any application has to become aware of the best practices for security
> for their particular domain...
I guess forcing is not really possible because we don't want to break
compatibility. but best practices doesn't reduce sloppiness. but we
should help to reduce it as good as we can ;)
> > Another option would be to add a new method to our request where you can
> > specify one or more filters:
> >
> > String p = request.getParameter("id","id-filter");
> >
> > So filtering would be very easy and as close as possible to the request
> > but not really forced - it would be an option we should document and
> > promote very well.
>
> This is a complex area. It seems a start, but there are other attacks that
> such an approach doesn't help.
<snip type="example"/>
I do understand your example... but it addresses a completely different
perspective. A much complexer as you have already stated.
For things like SQL, transformers and the sitemap simple filtering
should do it. We just need to make sure each individual parameter is ok.
Everything else is up to the webapp's decision. Plain filtering would
solve problems where we cannot supply webapp-like logic. Your example is
definitely a webapp case ;)
> Now, that doesn't mean we can't help them! Generalized filtering
> capabilities and generalized validation capabilities for Cocoon seems like a
> good idea. However, I think the capabilities need to be very extensible and
> very flexible.
I think it really depends on what you want to do with it...
<snip/>
> Adding yet another bit of semantics and complexity to the sitemap each time
> we hit a problem is starting to strike me as a bad way to go. Next thing you
> know we'll be promoting having a eXtensible Sitemap Language as a feature of
> Cocoon and there will be entire books devoted on just how to write a Cocoon
> sitemap (maybe that's not such a bad idea even now :-)...
I know... I also not in favor on the sitemap example I gave ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
