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] > > > > >
