The ResourceDigestGenerator by default secures files with extension:
.tml and .class. To add more restrictions you'd have to contribute
ResourceDigestGenerator. Something like this:
public static void
contributeResourceDigestGenerator(Configuration<String> configuration)
{
configuration.add("properties");
configuration.add("xml");
}
However i agree that this should be documented or even created by the
maven archetype. It's something a new user could easily forget with
devastating consequences.
On Fri, Aug 14, 2009 at 4:29 AM, kartweel<r...@exemail.com.au> wrote:
>
> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to be a lot
> about this topic. Was there ever a nice solution implemented for this? 2
> years of tapestry framework development later and I can still download all
> my class files. I've restricted assets to "authenticated users" using a
> method like below, but I thought by now we wouldn't need to be adding custom
> solutions to manage this and it would be part of the core project??
>
>
> Robert Zeigler wrote:
>>
>> I don't plan on changing the default configuration from whitelist to
>> blacklist... it's the fallback.
>> I'm a fan of "deny unless explicitly authorized", as well. The
>> AssetProtectionDispatcher
>> takes an ordered configuration of AssetPathAuthorizer's, with the
>> default whitelist implementation
>> being the "catch all" final authorizer in what amounts to a chain of
>> command. So you can certainly
>> contribute your own implementations of authorizer on top of the
>> default. Having a pattern matching
>> whitelist would certainly be useful; I'm in a time crunch at the
>> moment (and basically will be until the end of August),
>> but in the beginning of September, I will rework the default
>> WhitelistAuthorizer to accept url patterns.
>>
>> Robert
>>
>> On Aug 3, 2007, at 8/38:27 AM , Thiago H de Paula Figueiredo wrote:
>>
>>> On Fri, 03 Aug 2007 10:03:37 -0300, Francois Armand
>>> <farm...@linagora.com> wrote:
>>>
>>>> Thiago H de Paula Figueiredo wrote:
>>>>> Would a black list intead of a white list better? I suppose there
>>>>> are less files to hide than files to allow access.
>>>> Well, I think that one of the best principle in security is
>>>> "explicit authorization" : you just do not want that a
>>>> confidential file is accessible by error, because a user forgot to
>>>> hide it.
>>>
>>> That's a very good point. ;)
>>>
>>>> But I agree that the white list should authorize jokers to enable
>>>> "*.jpg" kind of filter (and if you name your confidential file
>>>> "picture_of_my_secret_weapon.jpg", well, to bad for you ;)
>>>
>>> Maybe we could allow any .jpg, .gif, .jpg and .css file by default
>>> and explicitly whitelist the rest.
>>> And no, I don't want to see the picture of your secret weapon,
>>> whatever it is. :P
>>>
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
