Nope. Zero configuration necessary for the basic functionality.
Keep in mind, however, that the default configuration is pretty
restrictive, since
it is whitelist-based, and the only entries added by default are the
assets that
come "out of the box" with tapestry (tapestry.css, tapestry.js, etc.).
So, you can either contribute a custom AssetPathAuthorizer
(if you don't like the default whitelist strategy...) or you can
contribute to the whitelist authorizer.
For instance, I'm using the jscalendar component (http://
code.google.com/p/tapestry5-jscalendar/
personally using a modified version that is compatible with
T5.0.5...), so I needed to make the assets it uses
available, so I have something like the following in my app module:
public static void contributeWhitelistAuthorizer(
Configuration<String> conf,
@Symbol("net.keso.ted.jscalendarscript.path") String
jscalendarPath) {
conf.add(jscalendarPath +"/calendar-blue.css");
conf.add(jscalendarPath + "/calendar.js");
conf.add(jscalendarPath + "/lang/calendar-en.js");
conf.add(jscalendarPath + "/calendar-setup.js");
conf.add(jscalendarPath + "/button-image.png");
}
Robert
PS: Noticed that I didn't mention the maven artifactId, etc. before
when I mentioned putting it into the maven repo...
groupId: com.saiwaisolutions
artifactId: AssetProtectionDispatcher
version: 0.0.1
On Aug 3, 2007, at 8/32:18 AM , Sabine K. wrote:
Hi Robert,
How to implement this component? Is it necessary to register the
component
in the appmodule?
Thx
Sabine
Robert Zeigler wrote:
Couple of comments...
First, the T5 asset service has the md5 feature. But the default
implementation, at the moment, only requires md5 hashing for
the .class files. (So, there's not an open door to the class bytes at
the moment. ;)
Second, I have a T5 app that should be going live in the next few
days. So I implemented an extensible AssetProtectorDispatcher. By
default, it uses a whitelist strategy, and the default configuration
will add the various tapestry assets (default.css, grid's components,
etc.) to the whitelist for you.
You can download it here:
http://www.tapestrycomponents.org/Tassel/app?service=external/
ViewComponent&sp=SAssetProtectionDispatcher
Or, if you're a maven user, I've got it in a personal maven repo
here:
http://www.saiwai-solutions.com/maven
Cheers.
Robert
On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:
I'm quite new to Tapestry and just 2 days ago have started working
with Tap 5. I realize the two (4 vs 5) are disparately different,
but one of the things nice about the Tap 4 asset service was the
checksum feature I mentioned that would deny access unless the sum
in the url matched that of the file. My newness to Tap may show
here, but why can't the asset service simply ignore requests for
files that are not marked (@Asset) as assets? I mean doesn't a deny-
all first and allow explicit exceptions strategy seem much more
sane then providing an open door to the whole classpath (class
bytes included??)?
Robert Zeigler wrote:
Asset service doesn't really need a configuration point here, imo.
You can already make contributions to services that would allow
you to implement this sort of content filtering.
For instance, you could contribute a RequestFilter. Alternatively,
you could contribute a Dispatcher to teh MasterDispatcher service.
Contributions to MasterDispatcher are ordered, so you can
contribute your "AssetBlockerDispatcher" before the asset service,
intercept requests to "forbidden" assets,
and respond appropriately. You could then make your custom
dispatcher (or request filter) configurable in the manner that you
desire.
You don't rewrite any of the asset service, you get your content
filtering, and you can write it as a drop-in module for any new
projects.
Robert
On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
Thiago, my apologies. You are correct. I would think this is
big a
problem if you can't hide important files from users!
Dan
On 7/26/07, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]>
wrote:
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
<[EMAIL PROTECTED]> wrote:
Hi, Just don't put configuration resources there.
I'm not sure you had understood what I've said.
My hibernate.cfg.xml is in /src/main/resources. So it is
copied by
Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
anything in
the classpath, as far as I can see, is accessible via
<applicatiourl>/assets. As many frameworks expect their
configuration
files to be in the classpath, I think we have a little, easy to
solve
problem here. :)
Thiago
-----------------------------------------------------------------
--
--
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]
-------------------------------------------------------------------
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context: http://www.nabble.com/-T5--Security-
of-files-in-the-classpath-tf4153267.html#a11978578
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
