I actually liked how the AssetDispatcher stuff worked - secured by default and only allowing the stuff that was explicitly makred as public on the classpath (e.g. css, images, etc). It seems to me that the default-open is a slippery slope from a security standpoint : today I might forget that I added some config file w/ a weird extension and tomorrow when I deploy, my configuration would be widely readable by the world. Not cool.
I liked the idea that was discussed previously, where if possible anything marked as an Asset would be available, everything else wouldn't; however, it seemed like there was no good technical solution for that. Regards, Alex K On Fri, Apr 9, 2010 at 2:15 AM, Joachim Van der Auwera <[email protected]>wrote: > Just protecting all files in the classpath may be a bit too strict. Why not > allow all graphics types (png/gif/jpeg) from everywhere? This makes the > integration of component libraries easier. > For example for using chenillekit in 5.2 you need to contribute a > RegexAuthorizer to see the images referred from the css files. > > Kind regards, > Joachim > > > Thiago H. de Paula Figueiredo wrote: > >> On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship <[email protected]> >> wrote: >> >> What should be available by default? My opinion, anything in the context, >>>> except WEB-INF. >>>> What should not be available by default? My opinion, anything in the >>>> classpath. >>>> >>> >>> And that's where I disagree; maybe any non .class file outside of a >>> controlled package should be protected? If we remove the malicious >>> user's ability to "hunt' for files and protect the ones that may be >>> important (.class, etc.) then we're good. >>> >> >> Configuration files are very sensitive and are usually located in the >> classpath in known places. I would consider most files in the classpath as >> something that aren't meant to be publicly accessible unless explicitly >> allowed. >> >> > > -- > Joachim Van der Auwera > PROGS bvba, progs.be > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
