Re: WARNING!: Thinking about breaking asset service MD5 digest of certain resources

[Ron Piterman]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]