I like that one as well. A compiled regexp pattern for each unprotected resource spec will also help the possible performance hits.
I guess in the interest of configurability tapestry won't be able to have anything unprotected by default, except perhaps for those resources tapestry itself uses. Does anyone see a need to ever protect css/js/image files like this? I'd like to make everything as configurable as possible, but if this config spec starts to grow unwieldy that wouldn't be pleasant either. I'll leave everything protected for now.. On 12/27/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > > I find this much better : > > <configuration foo> > <unprotected-resource contains="*.css" /> > <unprotected-resource contains="net/sf/tacos//*.js" /> > </configuration> > > Cheers, > Ron > > Jesse Kuhnert wrote: > > Fair enough, so is providing a default configuration like this > acceptable?: > > > > <configuration foo> > > <protected-resource contains="*.class" /> > > <protected-resource contains="hibernate.*" /> > > </configuration> > > > > ? > > On 12/27/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > > >>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] > >> > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
