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]
