for a discussion and suggestion see

http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html

quote "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. "


haven't tried that myself yet, but will need it in the near future.


IMHO it would make sense to include this in the
CryptedUrlWebRequestCodingStrategy.


regards
Antoine.





On Mon, Mar 1, 2010 at 4:01 PM, Sergey Olefir <solf.li...@gmail.com> wrote:
> Hi,
>
> out of the box Wicket generates urls for packaged resources that
> contain fully-qualified class names, e.g.:
> <link rel="stylesheet" type="text/css"
> href="resources/org.example.MyClassName/decorations/style.css" />
>
> Now in accordance with our security policies we are not allowed to
> expose internal application details -- and fully qualified class name
> certainly fits that category.
>
> On the other hand we do very much want to package resources together
> with the components that use them -- this approach seems to be way
> more convenient in practice than any other option.
>
> So I've been looking into whether it is possible to encrypt resource
> references (at least the class name part). My research led me to
> SharedResources.resourceKey(final Class<?> scope, final String path,
> final Locale locale, final String style)
> method which apparently is responsible for inserting FQNs into urls.
>
> Unfortunately this place seems to be locked down hard -- method is
> 'NOT PART OF THE WICKET PUBLIC API' and corresponding accessor method
> in Application is final. Moreover the field containing the instance in
> Application is private final -- so even reflection is no help.
>
> So any ideas how can I encrypt/obfuscate resource references without
> resorting to aliasing every single class on the classloader path?
> (aliasing 'as needed' is not really an option as it would be
> devilishly hard to ensure that there are no un-aliased urls as the
> system is developed in the future and new components/resources are
> added)
>
> ---------------------------------------------------------------------
> 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

Reply via email to