tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Kuhnert <jkuhn...@gmail.com>
Subject Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Date Thu, 05 Jan 2006 15:36:40 GMT
Context?

On 1/5/06, Andrea Chiumenti <kiuma.tapestry@wingstech.com> wrote:
>
> Ok, finally I setup my cvs:
> all, JFly source code will be deployed with an Apache Licence:
>
> To get jfly:
>
> CVSROOT=:pserver:anonymous@www.wingstech.it:/jfly; export CVSROOT
>
> cvs login
>
> and then get mudules and put them in the same directory:
>
> JFly.war
> JFlyBusiness
> JFlyCommons
> JFlyModel
> JFlyWebCommons
> JFlyWebComponents
> JFlyWebUsers
>
> You need to create a jfly db: currently I'm using postgresql 8.1 so the
> scripts ar for that db.
>
> After having created a jfly user (pwd jfly) execute the script you can
> find in
> JFlyModel/scripts/db/rebuild.sh
>
> then in order with Ant build modules (remember to change
> maven.ibiblio.url variable you find in file ibiblio.properties of each
> module root dir):
>
> JFlyCommons
> JFlyModel
> JFlyBusiness
> JFlyWebCommons
> JFlyWebComponents
> JFly.war
> JFlyWebUsers
>
>
> The final war is located in JFly.war/dist but it make more sense to use
> JFly in exploded form (root dir is JFly.war/JFly) so that you can easily
> add new modules to it.
>
> Feel free to contact me for any problem or if you have any suggestion
> for improvements or correction.
>
> (For the lateral menu I want to make it pluggable too using Hivemind, so
> that each module can bring its own submenu to ad to JFly application).
>
> cheers,
> kiuma
>
> On Thu, 2005-12-29 at 09:35 -0500, Jesse Kuhnert wrote:
> > That sounds very interesting. I'd love to see what you have done.
> >
> > On 12/29/05, kiuma <kiuma.tapestry@wingstech.com> 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 <jkuhnert@gmail.com>
> > > >To: Tapestry development
> > > ><tapestry-dev@jakarta.apache.org>
> > > >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 <rpiterman@gmx.net>
> > > >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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message