your impl breaks relative urls

consider a page served from /foo/bar that has a relative css ref to pretty.css

the url will be encrypted as /foo/bar/aaaaaaaaaaaaaa
and pretty.css reference will be processed as /foo/bar/pretty.css

now with your mapper we can have a situation like this

/foo/bar/aaaaa/bbbb

in which case the reference to css will become

/foo/bar/aaaaa/pretty.css

which is wrong.

perhaps the easiest fix is to create a version that puts the encrypted
string into a query parameter, in which case relative urls will be ok
and iis should be fine as well unless it doesnt support query
parameters over 260 chars long?

-igor

On Wed, Feb 22, 2012 at 6:05 AM, Jurriaan Pruys <[email protected]> wrote:
> Hi,
>
> Since this is my first post, I would like to thank you all for creating this 
> brilliant framework!
>
> (continuation of the discussion started on 
> https://issues.apache.org/jira/browse/WICKET-4407 , which now has resolution 
> "Won't Fix")
>
> CryptoMapper encrypts the whole Url into a single segment. As a result the 
> encrypted url segment can be very long (> 260 characters). The default 
> maximum url segment size for IIS is 260 characters (see 
> http://support.microsoft.com/kb/820129). The warning note for changing this 
> default is "Changing this registry key is considered extremely dangerous. 
> This key causes Http.sys to use more memory and may increase vulnerability to 
> malicious attacks."
> I've created my own CryptoMapper (see attachment in JIRA) that splits 
> encrypted request in separate segments when it's too long (and keep the 
> relative url logic). This works fine, but it would be nice to have this as a 
> default feature of CryptoMapper.
>
> Anyone has a better solution (which is easier to maintain)? Any chance I can 
> persuade someone to add an 'IIS compatibility / max segment size' option to 
> Wicket?
>
> Jurriaan

Reply via email to