So this means, that by default, assets commonly used in an application
(e.g. custom css, images, javascript) are blocked by default and the
user has to allow them manually? You don't want to add
RequestConstants.CONTEXT_FOLDER + appVersion + "/" + pathPattern to the
regex authorizer?
I'm all for blacklisting but reasonable defaults like allowing
css/jpg/png/gif/js from the webapp context IMHO should be added as not
to frustrate people trying to get their project going...
Uli
Robert Zeigler schrieb:
Fair enough. It was in there originally from when the module was
separate from the codebase; I suspect that a large portion of tapestry
users are also chenille-kit users (I know I am :), so I had added it in
for convenience. With the module moving into tapestry core, it makes
sense to move the "burden" of the contribution to the chenille-kit dev.
I should be closing out the ticket shortly, but it's pending one,
possibly two things:
1) An integration test asserting that the protection is in place
Note that existing integration tests illustrated the fact that it
/does/ work b/c they broke on addition of the module until I added the
appropriate contribution. But that's not the same thing as explicitly
testing for the presence of the protection.
2) Possibly adding in default contributions for the quickstart.
I've been hesitant to do this, honestly, because overriding such a
general contribution, while possible, is less straightforward (you'd
have to contribute your own implementation of an AssetAuthorizer in
front of the regex one). But as I was typing this I realized that we
can do it better than that by actually adding the contribution to the
quickstart's AppModule, rather than to tapestry core. So you still get
the benefit, but you can easily fine-tune the contribution.
Robert
On Nov 24, 2009, at 11/243:09 AM , Massimo Lusetti wrote:
On Mon, Nov 23, 2009 at 8:53 PM, Ulrich Stärk <[email protected]> wrote:
This will break all applications using chenillekit until the chenillekit
devs update their code and should be visibly documented somewhere.
We agree too and we have it in our tree a contribution that we will
extend to include everything needed.
Cheers
--
Massimo
http://meridio.blogspot.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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
