Re: Next 5.1 release?

[Christian Riedel <cr...@googlemail.com>]

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<jo...@progs.be>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<hl...@gmail.com>
>>>> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Best Regards / Viele Grüße
> 
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org