Now that 5.2.4 is almost final, don't forget about the bugfix release for 5.1! :-) Too many apps out there don't implement the workaround for the asset problem...
Am 20.04.2010 um 14:44 schrieb Sebastian Hennebrueder: > I don't believe that there is something like well known configuration files > or most likely public viewable images. We cannot know all existing nor > upcoming libraries and configuration files. For images the same is true. May > be the images are top secret and only delivered to logged in users. You can > never know. > > As a consequence, by default nothing should be public. It is just a security > best practise: Protect by default > > We should only mark things that should be public or alternatively follow the > JSF 2 approach to put resources into a dedicated folder. In JSF 2 this is > WEB-INF/resources/ > the latter would allow a simple approach to language specific JavaScript and > CSS as well. > > Yes, I know that it will break backward compatibility. > > Best Regards > > Sebastian Hennebrueder > > Am 09.04.10 08:26, schrieb Alex Kotchnev: >> 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] >>> >>> >> > > > > -- > Best Regards / Viele Grüße > > Sebastian Hennebrueder > ----- > Software Developer and Trainer for Hibernate / Java Persistence > http://www.laliluna.de > > > > --------------------------------------------------------------------- > 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]
