What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> the original design goal of the crypted strategy was to only encrypt
> what the user sees in the url bar. since they never see resource urls
> there was no reason to encrypt those.
>
> re fqns, you can add class aliases into SharedResources to hide those.
>
> -igor
>
> 2010/1/18 Sergejs Olefirs <sergejs.olef...@parex.lv>:
>> Hi,
>>
>> I started using Wicket rather recently. As part of our security
>> considerations, we do not want immediately expose the underlying
>> framework(s) we are using, so we went ahead with URL encryption. We used
>> standard approach as described in examples:
>>
>> @Override
>> protected IRequestCycleProcessor newRequestCycleProcessor() {
>>
>> return new WebRequestCycleProcessor(){
>> protected IRequestCodingStrategy newRequestCodingStrategy(){
>> return new CryptedUrlWebRequestCodingStrategy(new
>> WebRequestCodingStrategy());
>> }
>> };
>>
>> }
>>
>>
>> Unfortunately I later discovered that this approach doesn't encrypt resource
>> URLs, e.g. from:
>> CSSPackageResource.getHeaderContribution(..);
>> or
>> link.add(new Image("logoImage"));
>>
>> What's worse such resource references include FQN of related classes.
>>
>>
>> After some investigation I found out that the problem is that
>> CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
>> and WebRequestCodingStrategy encodes resource references as path rather than
>> as argument.
>>
>> I was able to get around this by subclassing WebRequestCodingStrategy and
>> overriding methods:
>> addResourceParameters(..);
>> encode(RequestCycle requestCycle, ISharedResourceRequestTarget
>> requestTarget);
>> to use arguments rather than path as resource reference.
>>
>>
>> However I'm unsure as to original reasoning behind original
>> CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
>> resource behaviour simply a bug? Or is it there for some reason that is
>> going to bite me down the road if I use my own 'fix'?
>>
>>
>> Best regards,
>> Sergey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
