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]
