I don't want to introduce non-backwards compatible solutions, plus I generally like having the resources in the same virtual folder as the classes.
I know I was very unhappy when I upgraded an app from 5.1 to 5.2 and stuff was broken. I want to avoid that. We're not talking about subtle API changes only used by a handful for inner-circle hard-core devs ... it's basic stuff and third party libraries that suddenly break, and the majority of users won't have the skills to figure out what broke and how to fix it. Anyway I see the solution like this: No resources in context:WEB-INF/ or classpath:META-INF/ can ever be exposed. No raw directory listing can be exposed. This is to prevent "fishing" attacks, but is actually not technically necessary. Context resources are always "safe". Classpath resources are either "safe" or "unsafe". Context file aliasing (for versioning and GZIP compression) can be turned off. This addresses the minority of applications where there are access rules for context assets. We just take Tapestry out of that loop and build ordinary URLs, not URLs under /assets. Classpath resources are presumed safe, but a configuration exists to identify safe and unsafe assets, using a regexp applied to the resource path (within the classpath) which maps to a boolean. The default is a "safe" resource. Some modules, such as the hibernate support module, will mark specific files (hibernate.cfg.xml) as unsafe. ".class" files are assumed unsafe. For "unsafe" resources, the URL must include an extra query parameter: the content hash. The content hash can only be computed from the content of the file, thus a URL including the query parameter must have been exposed deliberately by the application. Unsafe resources are expected to be very rare. Unsafe resources accessed without the query parameter (or with an invalid value) are rejected. The above represents an extension of the system used in Tapestry 4, with some minor improvements. Much of this is already present in Tapestry 5.0.18, but there were a few bugs (such as allowing directory listings, or not fully enforcing the need for proper content hashes). I expect to devote some time to this issue in the near future. On Tue, Feb 2, 2010 at 12:10 PM, Sebastian Hennebrueder <[email protected]> wrote: > Hi all, > > I am wondering why we don't adapt the approach introduced with JSF 2. > > CSS, JS and images can either be packed into > WebRoot/resources > or into > META-INF/resources of a JAR > > The advantage of this approach is that there is no need for a kind of bogus > regex or assumptions on what most users would like to show form the class > path. Even on pictures, you cannot assume that this is wanted by default. > May be people are hiding pictures in the class path and only show them to > logged in users. > > Defining a dedicated folder makes it pretty clear where to put things you > would like to show to the outside. > > I would sacrify security and expected behaviour (classpath is by default > protected) to backwards compatibility. > > A second benefit we could adapt from the JSF 2 approach is the possibility > to deliver resources depending on languages and versions > > Sample > webroot/resources/de/js/default.js/1.0.js > webroot/resources/de/js/default.js/1.1.js > webroot/resources/en/js/default.js/1.0.js > A user with a german locale (de), using the following tag will get the > newest version of the German script > webroot/resources/de/js/default.js/1.1.js > > <h:outputScript library="js" name="default.js" /> > > A page could use an older version as well. It just needs to specify the > resourceVersion. > > <h:outputScript library="js" resourceVersion="1.0" name="default.js" /> > > What do you think? > > -- > Best Regards / Viele Grüße > > Sebastian Hennebrueder > ----- > Software Developer and Trainer for Hibernate / Java Persistence > http://www.laliluna.de > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
