tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kiuma" <kiuma.tapes...@wingstech.com>
Subject Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Date Thu, 05 Jan 2006 16:15:46 GMT
IF you mean WebContext : http://localhost:8080/JFly

If you ask the reason why I gave this links is about I solved the css with jar problem reimplementing
the redirectors in module JFlyWebCommons, and I plugged pages into an application along with
jar.

kiuma

>----- ------- Original Message ------- -----
>From: Jesse Kuhnert <jkuhnert@gmail.com>
>To: Tapestry development
><tapestry-dev@jakarta.apache.org>
>Sent: Thu, 5 Jan 2006 10:36:40
>
>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
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message