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]
