Jesse Kuhnert wrote:
Thanks for all the feedback everyone has given so far, it's a lot easier
than trying to think of all the scenerios myself ;)
Here is what is currently implemented, which is basically a hivemind
configuration point:
<configuration foo..>
<unprotected-resource contains="/net/sf/tacos/ajax/components/.*.js" />
</configuration>
I like the idea of making people specifically unprotect things themselves,
because then we don't have to be liable for anyone getting hax0red. The only
issue I have with the per asset idea is that it breaks my own use-case,
which is a directory structure looking like:
/net/sf/tacos/ajax/dojo/dojo.js
/net/sf/tacos/ajax/dojo/src/bootstrap.js
/net/sf/tacos/ajax/dojo/src/etc....
You can define an asset for every one of those, and unprotect it.
The fact that you are not directly using the assets does not concern
tapestry...
as before - i am much more in favour of the asset way, more simple
control... (more ->, simple, control).
To get around the only major haxor flaw that I can see, which is using
../../ to move around the paths we could go with something more like:
<configuration foo..>
<unprotected-resource path="/net/sf/tacos/ajax/components/" contains=".*.js"
/>
</configuration>
breaking it to a path and filename wildcard sounds good.
you will however check it after you have accessed the resource.
We can then use this base path information to validate that whatever
resource they are requesting really is contained by the base path. This
would add a level of protection to a lot of obvious mistakes people might
make.
What do you guys think?
On 12/29/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
I just had a thought about RE and the unprotecting, which doesn't make
me very happy.
REs are very tricky, and depending on the code you use,
- say you unportect RE '*css'
- say you don't have $ at the end and don't match the whole expression
- say some one gives along 'org\a.css\..\..\..\WEB-INF\' and so forth...
I know I am very paranoid, but I think it comes from internet reality...
What about taking another strategy and making unprotection on a
'per-resource' strategy, using the xml.
Say we add an attribute to the <asset, called unprotec.
When tapestry processes the XML, the resource will get unprotected, once
(since tap. processes the xml once), for the whole application?
so you define
<asset ... unprotect="yes"/>
this would be better also because it brings the usage (which relies on
unprotection in some cases) and the unprotection itself very close
together.
Cheers,
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
