ok, added WICKET-2731
Antoine On Thu, Jan 21, 2010 at 4:52 PM, Igor Vaynberg <[email protected]> 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 > <[email protected]> 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 <[email protected]> >> 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 <[email protected]>: >>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> take your photos everywhere you go - https://www.memolio.com >> follow us on Twitter - http://twitter.com/Memolio >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
