Thanks for all the feedback everyone has given so far, it's a lot easier than trying to think of all the scenerios myself ;)
Here is what is currently implemented, which is basically a hivemind configuration point: <configuration foo..> <unprotected-resource contains="/net/sf/tacos/ajax/components/.*.js" /> </configuration> I like the idea of making people specifically unprotect things themselves, because then we don't have to be liable for anyone getting hax0red. The only issue I have with the per asset idea is that it breaks my own use-case, which is a directory structure looking like: /net/sf/tacos/ajax/dojo/dojo.js /net/sf/tacos/ajax/dojo/src/bootstrap.js /net/sf/tacos/ajax/dojo/src/etc.... To get around the only major haxor flaw that I can see, which is using ../../ to move around the paths we could go with something more like: <configuration foo..> <unprotected-resource path="/net/sf/tacos/ajax/components/" contains=".*.js" /> </configuration> We can then use this base path information to validate that whatever resource they are requesting really is contained by the base path. This would add a level of protection to a lot of obvious mistakes people might make. What do you guys think? On 12/29/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > > I just had a thought about RE and the unprotecting, which doesn't make > me very happy. > REs are very tricky, and depending on the code you use, > - say you unportect RE '*css' > - say you don't have $ at the end and don't match the whole expression > - say some one gives along 'org\a.css\..\..\..\WEB-INF\' and so forth... > > I know I am very paranoid, but I think it comes from internet reality... > > What about taking another strategy and making unprotection on a > 'per-resource' strategy, using the xml. > > Say we add an attribute to the <asset, called unprotec. > When tapestry processes the XML, the resource will get unprotected, once > (since tap. processes the xml once), for the whole application? > > so you define > > <asset ... unprotect="yes"/> > > this would be better also because it brings the usage (which relies on > unprotection in some cases) and the unprotection itself very close > together. > > Cheers, > Ron >
