Hi! I'm playing with tapestry and tacos to build an application framework (actually I don't know how to correctly define it). Basically it's a modularized application having a set of reusable components like ajax search list, frame decorators, pagers, etc.
If you want a preview I could post the entire source code (or even I could give an access to my site). I've redefined pager and asset encoders and do I was able to bring thing like tacos initialization and definition into these 'plugins'. If you are interested for a preview let me know. Anyway when things will a bit cleaner I think I'll open a new project on sf. Ceers, kiuma >----- ------- Original Message ------- ----- >From: Jesse Kuhnert <[EMAIL PROTECTED]> >To: Tapestry development ><[email protected]> >Sent: Thu, 29 Dec 2005 09:12:41 > >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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
