Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).

[Antoine van Wel <an...@gmail.com>]

ok, added WICKET-2731



Antoine




On Thu, Jan 21, 2010 at 4:52 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> not sure that is possible currently. the aliasing only works on a per
> class level. see SharedResources.putClassAlias().
>
> you can add an rfe to have it enhanced.
>
> seems like a quiet arbitrary requirement, especially when it comes to
> security. an fqn does not give anything away security-wise.
>
> -igor
>
>
>
> On Thu, Jan 21, 2010 at 1:18 AM, Antoine van Wel
> <an...@gmail.com> wrote:
>> 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 <ig...@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 <Se...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org