This can lead to awful security leaks where you write any kind of
dangerous resource in the classpath and it gets exposed by Tapestry.
hibernate.cfg.xml and hibernate.properties come to mind as examples of
non class files which we don't want to get exposed!
And they actually share extensions with possibly valid content
(especially the xml).
(And what if I want to share a class file as a web resource?)
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
I'm re-working some form of security back into the AssetService but am
having a real hard time justifying making the protected resources concept a
configurable option.
Specifically, all that I intend to do initially is protect all .class
resources. It feels very inefficient to imagine iterating/loooping/hash
lookup of incoming string values to the configured resources. I'm thinking
that maybe hard-coding (in some fashion) the .class extension logic may be a
better choice until someone presents a scenerio where they feel they need
more?
This wouldn't/shouldn't have any affect on sharing global resources and
such, just trying to make the asset service as simple/streamlined as
possible.
Thoughts are definitely welcome.
jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
