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
