Ups, sorry. The post was not for me.
-----Ursprüngliche Nachricht-----
Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Gesendet: Donnerstag, 21. Januar 2010 16:52
An: users@wicket.apache.org
Betreff: Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy =
resource URLs are not encrypted (bug?).
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
<antoine.van....@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 <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
>
>
---------------------------------------------------------------------
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
