See and I think that's just backwards. Yes its unfortunate that you can access the contents of WEB-INF (this was not intentional, clearly a bug), but the solution, then, is to not allow access to the contents of WEB-INF, rather than require the white-listing of everything not in WEB-INF.
I'd rather see some code that checked to see if the incoming asset path was for contents inside WEB-INF and 404 that. That's something hard and fast that can be written in code. On Thu, Dec 10, 2009 at 4:56 PM, Robert Zeigler <[email protected]> wrote: > So it turns out that 5.0 and >5.1 handle context assets differently. > > In 5.0, a reference like ${asset:context:foo.txt} will generate a URL like: > http://domain/context/foo.txt > > In 5.1, the same reference generates a URL like: > http://domain/context/assets/ctx/appversion/foo.txt > > Urls like: > http://domain/context/foo.txt > > still work, of course. The disconcerting thing is that: > http://domain/context/assets/ctx/appversion/WEB-INF/ > > also works. > And so does: > http://domain/context/assets/ctx/WEB-INF/web.xml > > And so forth. > > So we absolutely have to monitor assets of type ctx just like we monitor any > other asset request (and a contribution like: "^ctx.*$" is no good, either. > ;). > > Instead, we have a contribution that opens up context assets of type .js, > .css, .jpeg, .jpg, .png.... in other words, the most common cases. > It's easy enough to add additional contributions. > > But it was important to me that it be just as easy to turn off the > contribution. Because although context assets are available by default, > it's certainly possible to secure them, as well (via web.xml, and other > mechanisms). So I felt it important that the default contribution be easily > turned off. > > I'm willing to be wrong on this, but, I'm not convinced, yet. ;) > > Robert > > On Dec 10, 2009, at 12/104:19 PM , Howard Lewis Ship wrote: > >> Right, so again, where's the need to restrict the context coming from? >> I don't like this. >> >> On Thu, Dec 10, 2009 at 1:39 PM, Thiago H. de Paula Figueiredo >> <[email protected]> wrote: >>> >>> Em Thu, 10 Dec 2009 19:26:40 -0200, Howard Lewis Ship <[email protected]> >>> escreveu: >>> >>>> I still don't get why context assets, outside of WEB-INF, should ever >>>> be restricted? Did I miss that conversation? >>> >>> This was discussed yesterday. I'm also late to it. :( I think that >>> Tapestry >>> should come with reasonable defaults out of the box, and restricting >>> context >>> assets isn't reasonable, as they're accessible in a pure servlet >>> application. Anyway, if something is in the context and isn't below >>> WEB-INF, >>> it is meant to be public. The original problem was classpath files being >>> accessible by default. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, >>> and >>> instructor >>> Owner, software architect and developer, Ars Machina Tecnologia da >>> Informação Ltda. >>> http://www.arsmachina.com.br >>> >>> --------------------------------------------------------------------- >>> 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] > > > --------------------------------------------------------------------- > 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]
