Ok, scratch that comment too... I see Antoine dug up an old thread of yours where you already found out about the possibility to override WebRequestCodingStrategy.
I also see that Antoine created WICKET-2731 and that it has been closed as resolved/fixed, so there should be some hooks available in wicket 1.4.7 (which is to be release shortly according to the dev mailing list). Sergey Olefir wrote: > > As I briefly mentioned before, class aliases are, IMO, a terribly > unreliable thing to maintain. Every time someone comes up with new > component that uses resource reference they must not forget to go and > register the alias for it. > > I'm predicting a 100% probability that soon enough someone will forget it > and it'll go into production -- thus defeating the entire purpose behind > the encryption/obfuscation :) > > And to comment on what Antoine is saying -- I'm not entirely sure what did > you mean, but if I tried to implement encryption at > CryptedUrlWebRequestCodingStrategy, I will have to ensure that encrypted > URL will have format that will be fully parseable after browser appends > relative CSS URL to it. This is manageable by, say, encrypting only the > section of the path containing the class name. But then I'm completely > unsure as to how properly decode it / fake request for Wicket. The > existing code only 'fakes' parameters string -- but there are API methods > that deal with request path as well, and if those are not correct, I'm not > sure what issues that may cause. > > Bottom line -- it must be possible to do encryption at > CryptedUrlWebRequestCodingStrategy, but it will take some serious digging > to make sure all parts fit correctly. It would be far easier to e.g. > automatically add alias in SharedResources method that deals with > assigning the name to shared resource -- the only thing it'll require is > to modify Application class so that e.g. getSharedResources() is not > final. > > But I'm still hoping for some 'easy' solution that doesn't entail > modifying Wicket source code to avoid headaches when upgrading. > > > > bgooren wrote: >> >> The easiest way around this is to specify >> http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class, >> java.lang.String) class aliases . >> >> The upside is that you control the generated URL, the downside is that >> you have to make sure the alias is unique. >> > > -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754749.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
