You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jesse Kuhnert <jk...@gmail.com> on 2005/12/25 19:06:18 UTC
WARNING!: Thinking about breaking asset service MD5 digest of certain resources
I'm writing this message to be sure I haven't misunderstood what the
intentions of the asset service digestion of url strings were/are before I
go breaking them.
>From what I can tell the largest need for protection is that of .class files
because the asset service exposes the inner classloader resources of the
running jvm. This makes sense, but the protection of ALL resources this way
also hurts some other things.
I'm pondering creating a new hivemind configuration contribution that
defines what types of resources should be protected. This could go the other
way too, where it defines what types of resources ~shouldn't~ be protected,
but the first seems easiest. Initially I'm thinking that only resources
ending in .class file names will be protected.
This also starts the ball rolling on fixing the other issue we have, which
is the disconnect between the Shell component's js/css includes and those
private assets provided by libraries/components that wish to provide them. I
think that components should be able to auto-include their global resources
into the Shell component somehow. Not sure how yet. It could either be a
default that is allowed, additonally allowing hivemind configuration points
to exclude or disallow all or specific components/libraries from
contributing their global assets. This hints at the IAsset class starting
to have knowledge of types of resources, or at least a configurable string
grouping mechanism. Guess we can figure that one out when we get to it.
jesse
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Why don't you use Ant style expressions? As Acegi? I think it could be
clear enough for most people and if security projects use it to specify
security bindings why shouldn't Tapestry use it?
Something like:
<configuration GloballySafeAssets>
<asset path="/css/**/*" />
<asset path="*.js" />
</configuration>
<configuration UnprotectedAssets>
<unprotected-assets path="dojo/**/*" />
</configuration>
The nomenclature is not clear enough, IMO. I'd rather use ACCEPT / DENY and provide some good defaults.
<configuration AssetsSecurity>
<accept path="*.js" />
<deny ... />
</configuration>
... something like that.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
> That is precisely what I'm trying to avoid, having to explicitly list each
> and every unprotected asset. For something like dojo this just isn't a
> reasonable way of doing it.
>
> Ideally I'd like to see a solution that disallows mucking around with paths
> to get access to things, and also has inuitive defaults. Like making
> .css/.js/.html files unprotected by default. I'm always a fan of more
> comlicated logic within the framework that allows the user to do as little
> as possible to get up and running.
>
> In that vein, maybe an easier solution would be 2 configuration points:
>
> <configuration GloballySafeAssets>
> <asset extension="css" />
> <asset extension="js" />
> <asset extension="html" />
> <asset extension="htm" />
> </configuration>
>
> <configuration UnprotectedAssets>
> <unprotected-assets path="/net/sf/tacos/ajax" />
> </configuration>
>
> This configuration would allow security logic to ensure proper paths AND
> provide sensible defaults for unprotected resources, when people choose to
> enable them.
>
> Thoughts?
>
> jesse
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Ron Piterman <rp...@gmx.net>.
so what are the scenarios we are talking about?
wanting to uprotect
1. a single resource (+1)
2. all resources .xxx on path y (+1)
3. all resources .xxx on paths w , z , y (-1) (should be
4. all resources .xxx on all paths (-1)
5. all resources on path y (-0)
6. all resources on paths x, y, z (-0)
7. all resources on all pathes (-1)
I think these are all the options, or maybe I forgot some?
now if you use two conf. points, you can not really be that specific
about what you want.
you can not unprotect js from directory x and html from directory y.
That means, if you want a direct access to an html file inthe cp, you
will expose also html (templates) which reside in directory in which you
wish to expose js files. no good.
I would rather vote for the one before:
<unprotect path="/org/tacos/ajax/*" fn="*.js"/>
and make the wildcard very strict:
in directory : /org/tacos/ (only this directory) or /org/tacos/* (all
subdirs).
in fn : *.ext or dojo.js
nothing in between, so dojo* is not acceptable.
then wait for the usecases to come up in jira :)
Cheers,
Ron
Jesse Kuhnert wrote:
> That is precisely what I'm trying to avoid, having to explicitly list each
> and every unprotected asset. For something like dojo this just isn't a
> reasonable way of doing it.
>
> Ideally I'd like to see a solution that disallows mucking around with paths
> to get access to things, and also has inuitive defaults. Like making
> .css/.js/.html files unprotected by default. I'm always a fan of more
> comlicated logic within the framework that allows the user to do as little
> as possible to get up and running.
>
> In that vein, maybe an easier solution would be 2 configuration points:
>
> <configuration GloballySafeAssets>
> <asset extension="css" />
> <asset extension="js" />
> <asset extension="html" />
> <asset extension="htm" />
> </configuration>
>
> <configuration UnprotectedAssets>
> <unprotected-assets path="/net/sf/tacos/ajax" />
> </configuration>
>
> This configuration would allow security logic to ensure proper paths AND
> provide sensible defaults for unprotected resources, when people choose to
> enable them.
>
> Thoughts?
>
> jesse
>
>
>>>/net/sf/tacos/ajax/dojo/dojo.js
>>>/net/sf/tacos/ajax/dojo/src/bootstrap.js
>>>/net/sf/tacos/ajax/dojo/src/etc....
>>
>>You can define an asset for every one of those, and unprotect it.
>>The fact that you are not directly using the assets does not concern
>>tapestry...
>>
>>as before - i am much more in favour of the asset way, more simple
>>control... (more ->, simple, control).
>>
>>
>>>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>
>>
>>breaking it to a path and filename wildcard sounds good.
>>you will however check it after you have accessed the resource.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
That is precisely what I'm trying to avoid, having to explicitly list each
and every unprotected asset. For something like dojo this just isn't a
reasonable way of doing it.
Ideally I'd like to see a solution that disallows mucking around with paths
to get access to things, and also has inuitive defaults. Like making
.css/.js/.html files unprotected by default. I'm always a fan of more
comlicated logic within the framework that allows the user to do as little
as possible to get up and running.
In that vein, maybe an easier solution would be 2 configuration points:
<configuration GloballySafeAssets>
<asset extension="css" />
<asset extension="js" />
<asset extension="html" />
<asset extension="htm" />
</configuration>
<configuration UnprotectedAssets>
<unprotected-assets path="/net/sf/tacos/ajax" />
</configuration>
This configuration would allow security logic to ensure proper paths AND
provide sensible defaults for unprotected resources, when people choose to
enable them.
Thoughts?
jesse
> > /net/sf/tacos/ajax/dojo/dojo.js
> > /net/sf/tacos/ajax/dojo/src/bootstrap.js
> > /net/sf/tacos/ajax/dojo/src/etc....
>
> You can define an asset for every one of those, and unprotect it.
> The fact that you are not directly using the assets does not concern
> tapestry...
>
> as before - i am much more in favour of the asset way, more simple
> control... (more ->, simple, control).
>
> >
> > 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>
>
> breaking it to a path and filename wildcard sounds good.
> you will however check it after you have accessed the resource.
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Ron Piterman <rp...@gmx.net>.
Jesse Kuhnert wrote:
> 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....
You can define an asset for every one of those, and unprotect it.
The fact that you are not directly using the assets does not concern
tapestry...
as before - i am much more in favour of the asset way, more simple
control... (more ->, simple, control).
>
> 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>
breaking it to a path and filename wildcard sounds good.
you will however check it after you have accessed the resource.
>
> 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 <rp...@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
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <rp...@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
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Ron Piterman <rp...@gmx.net>.
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
Jesse Kuhnert wrote:
> I'm writing this message to be sure I haven't misunderstood what the
> intentions of the asset service digestion of url strings were/are before I
> go breaking them.
>
> From what I can tell the largest need for protection is that of .class files
> because the asset service exposes the inner classloader resources of the
> running jvm. This makes sense, but the protection of ALL resources this way
> also hurts some other things.
>
> I'm pondering creating a new hivemind configuration contribution that
> defines what types of resources should be protected. This could go the other
> way too, where it defines what types of resources ~shouldn't~ be protected,
> but the first seems easiest. Initially I'm thinking that only resources
> ending in .class file names will be protected.
>
> This also starts the ball rolling on fixing the other issue we have, which
> is the disconnect between the Shell component's js/css includes and those
> private assets provided by libraries/components that wish to provide them. I
> think that components should be able to auto-include their global resources
> into the Shell component somehow. Not sure how yet. It could either be a
> default that is allowed, additonally allowing hivemind configuration points
> to exclude or disallow all or specific components/libraries from
> contributing their global assets. This hints at the IAsset class starting
> to have knowledge of types of resources, or at least a configurable string
> grouping mechanism. Guess we can figure that one out when we get to it.
>
> jesse
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by David White <dw...@onemail.at>.
On Tue, 2005-12-27 at 12:55 -0500, Jesse Kuhnert wrote:
> I'm re-working some form of security back into the AssetService but am
> having a real hard time justifying making the protected resources concept a
> configurable option.
>
> Specifically, all that I intend to do initially is protect all .class
> resources. It feels very inefficient to imagine iterating/loooping/hash
> lookup of incoming string values to the configured resources. I'm thinking
> that maybe hard-coding (in some fashion) the .class extension logic may be a
> better choice until someone presents a scenerio where they feel they need
> more?
>
Yes, I can. We had a Tapestry 3.0 app that could read and
serve /etc/passwd and other nasties with appropriate path strings sent
as parameters.
This is potentially a very serious problem. I would suggest that assets
be perhaps restricted to a particular path in the *AR where it has been
deployed, like so for a resource with relative url <foo>:
WEB-INF/classes/ASSETS/<foo>
with no exceptions and no funky characters allowed.
This would break existing apps, of course, which is terrible and bad,
but preferable to the potential for harm in this behavior.
The unkeyed SHA-1 hash in the current implementation is still a hole, by
the way. Consider an embedded system, like a WLAN base station, using
Tapestry for its web interface (similar things exist ITW). A request for
the password database with a hash key obtained by running SHA-1 on the
default password db would be a simple, unobtrusive, and effective
scanner for such routers left in the default configuration...
Hope this helps,
David WHITE
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, it's starting to sound like that may be the case. I can always start
it off accepting all normal html-ish resources by default, like
css/js/images/etc..
Just trying to eliminate as many performance hits as possible. I'll have to
re-think how I'm doing this. ..
On 12/27/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Fair enough, so is providing a default configuration like this
> acceptable?:
>
> <configuration foo>
> <protected-resource contains="*.class" />
> <protected-resource contains="hibernate.*" />
> </configuration>
>
> ?
> On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> >
> > This can lead to awful security leaks where you write any kind of
> > dangerous resource in the classpath and it gets exposed by Tapestry.
> >
> > hibernate.cfg.xml and hibernate.properties come to mind as examples of
> > non class files which we don't want to get exposed!
> >
> > And they actually share extensions with possibly valid content
> > (especially the xml).
> > (And what if I want to share a class file as a web resource?)
> >
> > --
> > Ing. Leonardo Quijano Vincenzi
> > DTQ Software
> >
> >
> >
> > Jesse Kuhnert wrote:
> > > I'm re-working some form of security back into the AssetService but am
> >
> > > having a real hard time justifying making the protected resources
> > concept a
> > > configurable option.
> > >
> > > Specifically, all that I intend to do initially is protect all .class
> > > resources. It feels very inefficient to imagine
> > iterating/loooping/hash
> > > lookup of incoming string values to the configured resources. I'm
> > thinking
> > > that maybe hard-coding (in some fashion) the .class extension logic
> > may be a
> > > better choice until someone presents a scenerio where they feel they
> > need
> > > more?
> > >
> > > This wouldn't/shouldn't have any affect on sharing global resources
> > and
> > > such, just trying to make the asset service as simple/streamlined as
> > > possible.
> > >
> > > Thoughts are definitely welcome.
> > >
> > > jesse
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think I'm close to a compromise solution that will continue to use md5sum
digests, unless the incoming path resource is "unprotected".
The caching is something I'll have to work in as well. I'm hoping that i'll
be able to do a File(URL.getFile()).exists() on the path returned by the
resource and then doing an actual last modified check on it to determine the
caching. This would apply to unprotected resources only, which hopefully
won't even be requested by most modern browsers if they are functioning
correctly. (FF recently fixed caching on async io requests so that should
cover IE and FF at a minimum ).
I tried adding a unit test to compare execution time htis using the new
methods but either my box is too fast or the algorithm hit so low that there
is no discernable difference. (the test does assert that the runtime isn't
at least slower so it'll be easily pegged if the runtime performance
increases on a slower box than mine)
On 12/27/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> One of the advantages of the md5 encoding is that, for a file on the
> classpath (a virtual file system) ... when the contents of a file
> change, the path changes (since it incorporates the md5 sum of either
> the old or new version of the file). This is very useful, since
> Tapestry encourages the client to aggressively cache the file's
> content, knowing that any change will become, in effect, a new file
> with a new path.
>
> On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> > You can leave sensible defaults, but then you'd need to include some
> > sort of DENY / ACCEPT logic for people to override (mostly for
> > completeness).
> >
> > --
> > Ing. Leonardo Quijano Vincenzi
> > DTQ Software
> >
> >
> > Jesse Kuhnert wrote:
> > > I like that one as well. A compiled regexp pattern for each
> unprotected
> > > resource spec will also help the possible performance hits.
> > >
> > > I guess in the interest of configurability tapestry won't be able to
> have
> > > anything unprotected by default, except perhaps for those resources
> tapestry
> > > itself uses.
> > >
> > > Does anyone see a need to ever protect css/js/image files like this?
> I'd
> > > like to make everything as configurable as possible, but if this
> config spec
> > > starts to grow unwieldy that wouldn't be pleasant either.
> > >
> > > I'll leave everything protected for now..
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Howard Lewis Ship <hl...@gmail.com>.
One of the advantages of the md5 encoding is that, for a file on the
classpath (a virtual file system) ... when the contents of a file
change, the path changes (since it incorporates the md5 sum of either
the old or new version of the file). This is very useful, since
Tapestry encourages the client to aggressively cache the file's
content, knowing that any change will become, in effect, a new file
with a new path.
On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> You can leave sensible defaults, but then you'd need to include some
> sort of DENY / ACCEPT logic for people to override (mostly for
> completeness).
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
> Jesse Kuhnert wrote:
> > I like that one as well. A compiled regexp pattern for each unprotected
> > resource spec will also help the possible performance hits.
> >
> > I guess in the interest of configurability tapestry won't be able to have
> > anything unprotected by default, except perhaps for those resources tapestry
> > itself uses.
> >
> > Does anyone see a need to ever protect css/js/image files like this? I'd
> > like to make everything as configurable as possible, but if this config spec
> > starts to grow unwieldy that wouldn't be pleasant either.
> >
> > I'll leave everything protected for now..
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
You can leave sensible defaults, but then you'd need to include some
sort of DENY / ACCEPT logic for people to override (mostly for
completeness).
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
> I like that one as well. A compiled regexp pattern for each unprotected
> resource spec will also help the possible performance hits.
>
> I guess in the interest of configurability tapestry won't be able to have
> anything unprotected by default, except perhaps for those resources tapestry
> itself uses.
>
> Does anyone see a need to ever protect css/js/image files like this? I'd
> like to make everything as configurable as possible, but if this config spec
> starts to grow unwieldy that wouldn't be pleasant either.
>
> I'll leave everything protected for now..
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
I like that one as well. A compiled regexp pattern for each unprotected
resource spec will also help the possible performance hits.
I guess in the interest of configurability tapestry won't be able to have
anything unprotected by default, except perhaps for those resources tapestry
itself uses.
Does anyone see a need to ever protect css/js/image files like this? I'd
like to make everything as configurable as possible, but if this config spec
starts to grow unwieldy that wouldn't be pleasant either.
I'll leave everything protected for now..
On 12/27/05, Ron Piterman <rp...@gmx.net> wrote:
>
> I find this much better :
>
> <configuration foo>
> <unprotected-resource contains="*.css" />
> <unprotected-resource contains="net/sf/tacos//*.js" />
> </configuration>
>
> Cheers,
> Ron
>
> Jesse Kuhnert wrote:
> > Fair enough, so is providing a default configuration like this
> acceptable?:
> >
> > <configuration foo>
> > <protected-resource contains="*.class" />
> > <protected-resource contains="hibernate.*" />
> > </configuration>
> >
> > ?
> > On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> >
> >>This can lead to awful security leaks where you write any kind of
> >>dangerous resource in the classpath and it gets exposed by Tapestry.
> >>
> >>hibernate.cfg.xml and hibernate.properties come to mind as examples of
> >>non class files which we don't want to get exposed!
> >>
> >>And they actually share extensions with possibly valid content
> >>(especially the xml).
> >>(And what if I want to share a class file as a web resource?)
> >>
> >>--
> >>Ing. Leonardo Quijano Vincenzi
> >>DTQ Software
> >>
> >>
> >>
> >>Jesse Kuhnert wrote:
> >>
> >>>I'm re-working some form of security back into the AssetService but am
> >>>having a real hard time justifying making the protected resources
> >>
> >>concept a
> >>
> >>>configurable option.
> >>>
> >>>Specifically, all that I intend to do initially is protect all .class
> >>>resources. It feels very inefficient to imagine iterating/loooping/hash
> >>>lookup of incoming string values to the configured resources. I'm
> >>
> >>thinking
> >>
> >>>that maybe hard-coding (in some fashion) the .class extension logic may
> >>
> >>be a
> >>
> >>>better choice until someone presents a scenerio where they feel they
> >>
> >>need
> >>
> >>>more?
> >>>
> >>>This wouldn't/shouldn't have any affect on sharing global resources and
> >>>such, just trying to make the asset service as simple/streamlined as
> >>>possible.
> >>>
> >>>Thoughts are definitely welcome.
> >>>
> >>>jesse
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
>
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by liigo <li...@hotpop.com>.
在 Wed, 28 Dec 2005 02:32:50 +0800，Ron Piterman <rp...@gmx.net> 写道:
<configuration foo>
<protected-resource path="WEB_INF" exclude="*.html,*.jpeg,*.gif" />
<protected-resource contains="hibernate.*" />
</configuration>
> I find this much better :
>
> <configuration foo>
> <unprotected-resource contains="*.css" />
> <unprotected-resource contains="net/sf/tacos//*.js" />
> </configuration>
>
> Cheers,
> Ron
>
> Jesse Kuhnert wrote:
>> Fair enough, so is providing a default configuration like this
>> acceptable?:
>> <configuration foo>
>> <protected-resource contains="*.class" />
>> <protected-resource contains="hibernate.*" />
>> </configuration>
>> ?
>> On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>>
>>> This can lead to awful security leaks where you write any kind of
>>> dangerous resource in the classpath and it gets exposed by Tapestry.
>>>
>>> hibernate.cfg.xml and hibernate.properties come to mind as examples of
>>> non class files which we don't want to get exposed!
>>>
>>> And they actually share extensions with possibly valid content
>>> (especially the xml).
>>> (And what if I want to share a class file as a web resource?)
>>>
>>> --
>>> Ing. Leonardo Quijano Vincenzi
>>> DTQ Software
>>>
>>>
>>>
>>> Jesse Kuhnert wrote:
>>>
>>>> I'm re-working some form of security back into the AssetService but am
>>>> having a real hard time justifying making the protected resources
>>>
>>> concept a
>>>
>>>> configurable option.
>>>>
>>>> Specifically, all that I intend to do initially is protect all .class
>>>> resources. It feels very inefficient to imagine
>>>> iterating/loooping/hash
>>>> lookup of incoming string values to the configured resources. I'm
>>>
>>> thinking
>>>
>>>> that maybe hard-coding (in some fashion) the .class extension logic
>>>> may
>>>
>>> be a
>>>
>>>> better choice until someone presents a scenerio where they feel they
>>>
>>> need
>>>
>>>> more?
>>>>
>>>> This wouldn't/shouldn't have any affect on sharing global resources
>>>> and
>>>> such, just trying to make the asset service as simple/streamlined as
>>>> possible.
>>>>
>>>> Thoughts are definitely welcome.
>>>>
>>>> jesse
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Ron Piterman <rp...@gmx.net>.
I find this much better :
<configuration foo>
<unprotected-resource contains="*.css" />
<unprotected-resource contains="net/sf/tacos//*.js" />
</configuration>
Cheers,
Ron
Jesse Kuhnert wrote:
> Fair enough, so is providing a default configuration like this acceptable?:
>
> <configuration foo>
> <protected-resource contains="*.class" />
> <protected-resource contains="hibernate.*" />
> </configuration>
>
> ?
> On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
>>This can lead to awful security leaks where you write any kind of
>>dangerous resource in the classpath and it gets exposed by Tapestry.
>>
>>hibernate.cfg.xml and hibernate.properties come to mind as examples of
>>non class files which we don't want to get exposed!
>>
>>And they actually share extensions with possibly valid content
>>(especially the xml).
>>(And what if I want to share a class file as a web resource?)
>>
>>--
>>Ing. Leonardo Quijano Vincenzi
>>DTQ Software
>>
>>
>>
>>Jesse Kuhnert wrote:
>>
>>>I'm re-working some form of security back into the AssetService but am
>>>having a real hard time justifying making the protected resources
>>
>>concept a
>>
>>>configurable option.
>>>
>>>Specifically, all that I intend to do initially is protect all .class
>>>resources. It feels very inefficient to imagine iterating/loooping/hash
>>>lookup of incoming string values to the configured resources. I'm
>>
>>thinking
>>
>>>that maybe hard-coding (in some fashion) the .class extension logic may
>>
>>be a
>>
>>>better choice until someone presents a scenerio where they feel they
>>
>>need
>>
>>>more?
>>>
>>>This wouldn't/shouldn't have any affect on sharing global resources and
>>>such, just trying to make the asset service as simple/streamlined as
>>>possible.
>>>
>>>Thoughts are definitely welcome.
>>>
>>>jesse
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
Fair enough, so is providing a default configuration like this acceptable?:
<configuration foo>
<protected-resource contains="*.class" />
<protected-resource contains="hibernate.*" />
</configuration>
?
On 12/27/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
> This can lead to awful security leaks where you write any kind of
> dangerous resource in the classpath and it gets exposed by Tapestry.
>
> hibernate.cfg.xml and hibernate.properties come to mind as examples of
> non class files which we don't want to get exposed!
>
> And they actually share extensions with possibly valid content
> (especially the xml).
> (And what if I want to share a class file as a web resource?)
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
> Jesse Kuhnert wrote:
> > I'm re-working some form of security back into the AssetService but am
> > having a real hard time justifying making the protected resources
> concept a
> > configurable option.
> >
> > Specifically, all that I intend to do initially is protect all .class
> > resources. It feels very inefficient to imagine iterating/loooping/hash
> > lookup of incoming string values to the configured resources. I'm
> thinking
> > that maybe hard-coding (in some fashion) the .class extension logic may
> be a
> > better choice until someone presents a scenerio where they feel they
> need
> > more?
> >
> > This wouldn't/shouldn't have any affect on sharing global resources and
> > such, just trying to make the asset service as simple/streamlined as
> > possible.
> >
> > Thoughts are definitely welcome.
> >
> > jesse
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
This can lead to awful security leaks where you write any kind of
dangerous resource in the classpath and it gets exposed by Tapestry.
hibernate.cfg.xml and hibernate.properties come to mind as examples of
non class files which we don't want to get exposed!
And they actually share extensions with possibly valid content
(especially the xml).
(And what if I want to share a class file as a web resource?)
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
> I'm re-working some form of security back into the AssetService but am
> having a real hard time justifying making the protected resources concept a
> configurable option.
>
> Specifically, all that I intend to do initially is protect all .class
> resources. It feels very inefficient to imagine iterating/loooping/hash
> lookup of incoming string values to the configured resources. I'm thinking
> that maybe hard-coding (in some fashion) the .class extension logic may be a
> better choice until someone presents a scenerio where they feel they need
> more?
>
> This wouldn't/shouldn't have any affect on sharing global resources and
> such, just trying to make the asset service as simple/streamlined as
> possible.
>
> Thoughts are definitely welcome.
>
> jesse
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: WARNING!: Thinking about breaking asset service MD5 digest of
certain resources
Posted by Ron Piterman <rp...@gmx.net>.
Hi Jesse,
to me this seems not enough.
What about .html/.jwc/.page files?
what about .library files ?
what about .property files ?
and many others which may be on the classpath (like
META-INF/hivemodule.xml )
and most important: As far as I can remember, when using ../../../ at
the from of the path for the asset service, one can access, if not
limited by JVM security constraints, any file on the server.
Why not go the other way around (conservative vs. libetal security) :
make the files which do *not* need protection configurable.
Cheers,
Ron
Jesse Kuhnert wrote:
> I'm re-working some form of security back into the AssetService but am
> having a real hard time justifying making the protected resources concept a
> configurable option.
>
> Specifically, all that I intend to do initially is protect all .class
> resources. It feels very inefficient to imagine iterating/loooping/hash
> lookup of incoming string values to the configured resources. I'm thinking
> that maybe hard-coding (in some fashion) the .class extension logic may be a
> better choice until someone presents a scenerio where they feel they need
> more?
>
> This wouldn't/shouldn't have any affect on sharing global resources and
> such, just trying to make the asset service as simple/streamlined as
> possible.
>
> Thoughts are definitely welcome.
>
> jesse
> On 12/25/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
>>The extension mechanism feels dirty to me, because it just sounds like
>>something that could easily be tricked by hacker types, I just can't think
>>of a scenerio where that's true yet.
>>
>>The ultimate problem I'm initially trying to solve is getting my old
>>friend dojo to work with the asset service. It does async io requests for
>>.js/.css/.html files relative to it's root context on an "as needed" basis.
>>This sort of breaks the current impl because the urls are definitely not
>>handed out by the asset service beforehand.
>>
>>Your idea may be good as well, my brain isn't following the parsing and
>>url rewriting part as easily though. Maybe you are giving me too much credit
>>;)
>>
>>I definitely don't want to ~hack~ in fixes for my problems though, if this
>>isn't ideal I can stop and re-think.
>>
>>On 12/25/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>>>I was thinking about this as well. Not protecting certain resources,
>>>by extension, may be a very good solution. It's probably easier to
>>>implement than my idea, which is to parse CSS files and rewrite URLs.
>>>
>>>On 12/25/05, Jesse Kuhnert < jkuhnert@gmail.com> wrote:
>>>
>>>>I'm writing this message to be sure I haven't misunderstood what the
>>>>intentions of the asset service digestion of url strings were/are
>>>
>>>before I
>>>
>>>>go breaking them.
>>>>
>>>>>From what I can tell the largest need for protection is that of .class
>>>
>>>files
>>>
>>>>because the asset service exposes the inner classloader resources of
>>>
>>>the
>>>
>>>>running jvm. This makes sense, but the protection of ALL resources
>>>
>>>this way
>>>
>>>>also hurts some other things.
>>>>
>>>>I'm pondering creating a new hivemind configuration contribution that
>>>>defines what types of resources should be protected. This could go the
>>>
>>>other
>>>
>>>>way too, where it defines what types of resources ~shouldn't~ be
>>>
>>>protected,
>>>
>>>>but the first seems easiest. Initially I'm thinking that only
>>>
>>>resources
>>>
>>>>ending in .class file names will be protected.
>>>>
>>>>This also starts the ball rolling on fixing the other issue we have,
>>>
>>>which
>>>
>>>>is the disconnect between the Shell component's js/css includes and
>>>
>>>those
>>>
>>>>private assets provided by libraries/components that wish to provide
>>>
>>>them. I
>>>
>>>>think that components should be able to auto-include their global
>>>
>>>resources
>>>
>>>>into the Shell component somehow. Not sure how yet. It could either be
>>>
>>>a
>>>
>>>>default that is allowed, additonally allowing hivemind configuration
>>>
>>>points
>>>
>>>>to exclude or disallow all or specific components/libraries from
>>>>contributing their global assets. This hints at the IAsset class
>>>
>>>starting
>>>
>>>>to have knowledge of types of resources, or at least a configurable
>>>
>>>string
>>>
>>>>grouping mechanism. Guess we can figure that one out when we get to
>>>
>>>it.
>>>
>>>>jesse
>>>>
>>>>
>>>
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Independent J2EE / Open-Source Java Consultant
>>>Creator, Jakarta Tapestry
>>>Creator, Jakarta HiveMind
>>>
>>>Professional Tapestry training, mentoring, support
>>>and project work. http://howardlewisship.com
>>>
>>>---------------------------------------------------------------------
>>>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
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
I'm re-working some form of security back into the AssetService but am
having a real hard time justifying making the protected resources concept a
configurable option.
Specifically, all that I intend to do initially is protect all .class
resources. It feels very inefficient to imagine iterating/loooping/hash
lookup of incoming string values to the configured resources. I'm thinking
that maybe hard-coding (in some fashion) the .class extension logic may be a
better choice until someone presents a scenerio where they feel they need
more?
This wouldn't/shouldn't have any affect on sharing global resources and
such, just trying to make the asset service as simple/streamlined as
possible.
Thoughts are definitely welcome.
jesse
On 12/25/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> The extension mechanism feels dirty to me, because it just sounds like
> something that could easily be tricked by hacker types, I just can't think
> of a scenerio where that's true yet.
>
> The ultimate problem I'm initially trying to solve is getting my old
> friend dojo to work with the asset service. It does async io requests for
> .js/.css/.html files relative to it's root context on an "as needed" basis.
> This sort of breaks the current impl because the urls are definitely not
> handed out by the asset service beforehand.
>
> Your idea may be good as well, my brain isn't following the parsing and
> url rewriting part as easily though. Maybe you are giving me too much credit
> ;)
>
> I definitely don't want to ~hack~ in fixes for my problems though, if this
> isn't ideal I can stop and re-think.
>
> On 12/25/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > I was thinking about this as well. Not protecting certain resources,
> > by extension, may be a very good solution. It's probably easier to
> > implement than my idea, which is to parse CSS files and rewrite URLs.
> >
> > On 12/25/05, Jesse Kuhnert < jkuhnert@gmail.com> wrote:
> > > I'm writing this message to be sure I haven't misunderstood what the
> > > intentions of the asset service digestion of url strings were/are
> > before I
> > > go breaking them.
> > >
> > > From what I can tell the largest need for protection is that of .class
> > files
> > > because the asset service exposes the inner classloader resources of
> > the
> > > running jvm. This makes sense, but the protection of ALL resources
> > this way
> > > also hurts some other things.
> > >
> > > I'm pondering creating a new hivemind configuration contribution that
> > > defines what types of resources should be protected. This could go the
> > other
> > > way too, where it defines what types of resources ~shouldn't~ be
> > protected,
> > > but the first seems easiest. Initially I'm thinking that only
> > resources
> > > ending in .class file names will be protected.
> > >
> > > This also starts the ball rolling on fixing the other issue we have,
> > which
> > > is the disconnect between the Shell component's js/css includes and
> > those
> > > private assets provided by libraries/components that wish to provide
> > them. I
> > > think that components should be able to auto-include their global
> > resources
> > > into the Shell component somehow. Not sure how yet. It could either be
> > a
> > > default that is allowed, additonally allowing hivemind configuration
> > points
> > > to exclude or disallow all or specific components/libraries from
> > > contributing their global assets. This hints at the IAsset class
> > starting
> > > to have knowledge of types of resources, or at least a configurable
> > string
> > > grouping mechanism. Guess we can figure that one out when we get to
> > it.
> > >
> > > jesse
> > >
> > >
> >
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work. http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
The extension mechanism feels dirty to me, because it just sounds like
something that could easily be tricked by hacker types, I just can't think
of a scenerio where that's true yet.
The ultimate problem I'm initially trying to solve is getting my old friend
dojo to work with the asset service. It does async io requests for
.js/.css/.html files relative to it's root context on an "as needed" basis.
This sort of breaks the current impl because the urls are definitely not
handed out by the asset service beforehand.
Your idea may be good as well, my brain isn't following the parsing and url
rewriting part as easily though. Maybe you are giving me too much credit ;)
I definitely don't want to ~hack~ in fixes for my problems though, if this
isn't ideal I can stop and re-think.
On 12/25/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> I was thinking about this as well. Not protecting certain resources,
> by extension, may be a very good solution. It's probably easier to
> implement than my idea, which is to parse CSS files and rewrite URLs.
>
> On 12/25/05, Jesse Kuhnert <jk...@gmail.com> wrote:
> > I'm writing this message to be sure I haven't misunderstood what the
> > intentions of the asset service digestion of url strings were/are before
> I
> > go breaking them.
> >
> > From what I can tell the largest need for protection is that of .class
> files
> > because the asset service exposes the inner classloader resources of the
> > running jvm. This makes sense, but the protection of ALL resources this
> way
> > also hurts some other things.
> >
> > I'm pondering creating a new hivemind configuration contribution that
> > defines what types of resources should be protected. This could go the
> other
> > way too, where it defines what types of resources ~shouldn't~ be
> protected,
> > but the first seems easiest. Initially I'm thinking that only resources
> > ending in .class file names will be protected.
> >
> > This also starts the ball rolling on fixing the other issue we have,
> which
> > is the disconnect between the Shell component's js/css includes and
> those
> > private assets provided by libraries/components that wish to provide
> them. I
> > think that components should be able to auto-include their global
> resources
> > into the Shell component somehow. Not sure how yet. It could either be a
> > default that is allowed, additonally allowing hivemind configuration
> points
> > to exclude or disallow all or specific components/libraries from
> > contributing their global assets. This hints at the IAsset class
> starting
> > to have knowledge of types of resources, or at least a configurable
> string
> > grouping mechanism. Guess we can figure that one out when we get to it.
> >
> > jesse
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources
Posted by Howard Lewis Ship <hl...@gmail.com>.
I was thinking about this as well. Not protecting certain resources,
by extension, may be a very good solution. It's probably easier to
implement than my idea, which is to parse CSS files and rewrite URLs.
On 12/25/05, Jesse Kuhnert <jk...@gmail.com> wrote:
> I'm writing this message to be sure I haven't misunderstood what the
> intentions of the asset service digestion of url strings were/are before I
> go breaking them.
>
> From what I can tell the largest need for protection is that of .class files
> because the asset service exposes the inner classloader resources of the
> running jvm. This makes sense, but the protection of ALL resources this way
> also hurts some other things.
>
> I'm pondering creating a new hivemind configuration contribution that
> defines what types of resources should be protected. This could go the other
> way too, where it defines what types of resources ~shouldn't~ be protected,
> but the first seems easiest. Initially I'm thinking that only resources
> ending in .class file names will be protected.
>
> This also starts the ball rolling on fixing the other issue we have, which
> is the disconnect between the Shell component's js/css includes and those
> private assets provided by libraries/components that wish to provide them. I
> think that components should be able to auto-include their global resources
> into the Shell component somehow. Not sure how yet. It could either be a
> default that is allowed, additonally allowing hivemind configuration points
> to exclude or disallow all or specific components/libraries from
> contributing their global assets. This hints at the IAsset class starting
> to have knowledge of types of resources, or at least a configurable string
> grouping mechanism. Guess we can figure that one out when we get to it.
>
> jesse
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org