Isn't this simply due to a Maven convention which has passed its "use
by" date? Why not put .java, .tml, and .properties together in the
source tree, and compile them all into WEB-INF/classes/ where they're
automatically hidden from the users? Surely this makes so much sense.
It's what I do with Ant and it seems to work a treat. Or have I missed
something?
Eg. correct me if I'm wrong but I'm pretty sure that only the css and
images are downloadable from here: http://jumpstart.doublenegative.com.au:8080/jumpstart/
Geoff
On 14/08/2009, at 7:07 PM, Juan E. Maya wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
