That sounds very interesting. I'd love to see what you have done.
On 12/29/05, kiuma <[EMAIL PROTECTED]> wrote: > > 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] > >
