Or you could just resolve the relative path to an absolute path and
apply the existing rule for /path/to/secure/resource?
Am 19.01.10 21:21, schrieb Ulrich Stärk:
I see. So all we want to forbid is two consecutive dots in the path
part, i.e. before the last /, right?
Uli
On 19.01.2010 18:45 schrieb Robert Zeigler:
To avoid attempts at circumventing restrictions via relative path
specifications:
/path/to/available/resource/../../../../path/to/secure/resource
Some (most? all?) browsers will kindly get rid of the relative path
reference from the request, but it's certainly possible via, eg, curl,
wget, etc. to craft such a request. Since we're not actually resolving
the asset and determining the absolute location, only looking at the
requested path via regex, it's prudent to deter such attempts.
Robert
On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
What was the rationale behind not allowing dots in the path part of
the URL and additional dots in the filename?
Are there any objections against allowing them?
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
