Re: How to encrypt/obfuscate resource reference?
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--tp27744679p27754197.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
Re: How to encrypt/obfuscate resource reference?
Sorry, I overlooked that part of your original post. I've been toying with the same idea, since class aliases are bound to cause problems as projects grow bigger. As long as the aliases are user-generated, they might not be unique. So I had a quick look at the source code of WebRequestCodingStrategy, and I think it should be possible to create a solution for your problem quite easily: 1) subclass WebRequestCodingStrategy, and use it by overriding newRequestCycleProcessor() in your application, and return a subclasses WebRequestCycleProcessor which returns your custom WebRequestCodingStrategy in the call to newRequestCodingStrategy(). Quickest solution is to create an anonymous inner class for the custom WebRequestCycleProcessor 2) override the http://wicket.apache.org/docs/1.4/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.html#encode(org.apache.wicket.RequestCycle, org.apache.wicket.request.target.resource.ISharedResourceRequestTarget) encode method which deals with shared resources, and implement encryption (or simply an obfuscated, stable alias for classes) 3) override http://wicket.apache.org/docs/1.4/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.html#addResourceParameters(org.apache.wicket.Request, org.apache.wicket.request.RequestParameters) addResourceParameters() and implement decryption 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--tp27744679p27754615.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
Re: How to encrypt/obfuscate resource reference?
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
Re: How to encrypt/obfuscate resource reference?
Thing is, I already toyed with WebRequestCodingStrategy -- specifically I changed how resources are encoded by replacing URL path with URL parameter. And I broke CSS/relative references in the process as I found out much later :) (as you found out already in your another post ;)) Although if I do something less drastic -- such as simply encoding the section with FQN -- I might break less stuff... Ah well, as you pointed out (and special thanks for that :)), 1.4.7 hopefully will be out soon with the some fix for the issue, maybe I can just wait it out. bgooren wrote: So I had a quick look at the source code of WebRequestCodingStrategy, and I think it should be possible to create a solution for your problem quite easily: -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754796.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
Re: How to encrypt/obfuscate resource reference?
A flag has been introduced that when set will throw an error when an fqn would be used. It will be in 1.4.7, which is currently in the voting phase, so it will be available within a week. But this would mean you'd have to alias all the classes anyway. Antoine On Tue, Mar 2, 2010 at 12:33 PM, Sergey Olefir solf.li...@gmail.com wrote: Thing is, I already toyed with WebRequestCodingStrategy -- specifically I changed how resources are encoded by replacing URL path with URL parameter. And I broke CSS/relative references in the process as I found out much later :) (as you found out already in your another post ;)) Although if I do something less drastic -- such as simply encoding the section with FQN -- I might break less stuff... Ah well, as you pointed out (and special thanks for that :)), 1.4.7 hopefully will be out soon with the some fix for the issue, maybe I can just wait it out. bgooren wrote: So I had a quick look at the source code of WebRequestCodingStrategy, and I think it should be possible to create a solution for your problem quite easily: -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754796.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 -- 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
Re: How to encrypt/obfuscate resource reference?
Thanks for heads up. I guess it's back to hacking WebRequestCodingStrategy for me, the flag is better than nothing, but I'm not eager in having application crash in production because someone forgot to map something and somehow it slipped past testing. Antoine van Wel wrote: A flag has been introduced that when set will throw an error when an fqn would be used. It will be in 1.4.7, which is currently in the voting phase, so it will be available within a week. But this would mean you'd have to alias all the classes anyway. -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754862.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
Re: How to encrypt/obfuscate resource reference?
Create a unit test case that scans your application for resources and checks if the class is set. If not, fail. If set, check if it is unique, if not fail. Martijn On Tue, Mar 2, 2010 at 12:40 PM, Sergey Olefir solf.li...@gmail.com wrote: Thanks for heads up. I guess it's back to hacking WebRequestCodingStrategy for me, the flag is better than nothing, but I'm not eager in having application crash in production because someone forgot to map something and somehow it slipped past testing. Antoine van Wel wrote: A flag has been introduced that when set will throw an error when an fqn would be used. It will be in 1.4.7, which is currently in the voting phase, so it will be available within a week. But this would mean you'd have to alias all the classes anyway. -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754862.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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to encrypt/obfuscate resource reference?
Err, I guess I don't quite understand what you're proposing... My understanding is that I need to know all class names that are used by application as part of ResourceReference (and possibly something else too). How would I scan for that? Martijn Dashorst wrote: Create a unit test case that scans your application for resources and checks if the class is set. If not, fail. If set, check if it is unique, if not fail. Martijn -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.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
Re: How to encrypt/obfuscate resource reference?
Take a look at the spring component scanner for an implementation of how to search the class path. Then it is just a series of ResourceReference.class.isAssignableFrom(clz) queries and applying your specific logic. For example we use the following code to scan for specific patterns in html files (such as style= attributes in html code, which we consider illegal—use classes and stylesheets instead). ResourcePatternResolver, PathMatchingResourcePatternResolver are classes that comes from Spring. ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver(); for (String packageName : getPackageNames()) { String usePackageName = packageName; if (!usePackageName.endsWith(.)) usePackageName += .; String filePatter = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX + ClassUtils.convertClassNameToResourcePath(usePackageName) + **/*.html; try { Resource[] resources = resourcePatternResolver.getResources(filePatter); for (Resource resource : resources) { if (resource.isReadable()) { ListString matches = getMatches(resource.getInputStream(), pattern); String fileName = resource.getURI().getPath(); if (errorWhenFound) { if (!matches.isEmpty()) addError(fileName + : + matches); } else { if (matches.isEmpty()) addError(fileName); } } } } catch (IOException e) { addError(e.getMessage()); } } assertNoErrors(message); Martijn On Tue, Mar 2, 2010 at 12:56 PM, Sergey Olefir solf.li...@gmail.com wrote: Err, I guess I don't quite understand what you're proposing... My understanding is that I need to know all class names that are used by application as part of ResourceReference (and possibly something else too). How would I scan for that? Martijn Dashorst wrote: Create a unit test case that scans your application for resources and checks if the class is set. If not, fail. If set, check if it is unique, if not fail. Martijn -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to encrypt/obfuscate resource reference?
I admit I didn't research in-depth what you've suggested, but from the quoted piece it seems that your suggestion will find all subclasses of ResourceReference. But to actually test that all resources are properly mapped, it would be necessary to locate all invocations of the ResourceReference constructors and scan their parameters. I have hard time imagining how it could possibly work without resorting to AspectJ (or AOP in general). Also the same problem may be relevant for e.g. Image() and possibly other stuff. Basically, unless I completely misunderstand what you're suggesting, I don't really see how such scanning might work. Martijn Dashorst wrote: Take a look at the spring component scanner for an implementation of how to search the class path. Then it is just a series of ResourceReference.class.isAssignableFrom(clz) queries and applying your specific logic. -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27756016.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
Re: How to encrypt/obfuscate resource reference?
You might also look into the scannotation project. On Tue, Mar 2, 2010 at 8:33 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Take a look at the spring component scanner for an implementation of how to search the class path. Then it is just a series of ResourceReference.class.isAssignableFrom(clz) queries and applying your specific logic. For example we use the following code to scan for specific patterns in html files (such as style= attributes in html code, which we consider illegal—use classes and stylesheets instead). ResourcePatternResolver, PathMatchingResourcePatternResolver are classes that comes from Spring. ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver(); for (String packageName : getPackageNames()) { String usePackageName = packageName; if (!usePackageName.endsWith(.)) usePackageName += .; String filePatter = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX + ClassUtils.convertClassNameToResourcePath(usePackageName) + **/*.html; try { Resource[] resources = resourcePatternResolver.getResources(filePatter); for (Resource resource : resources) { if (resource.isReadable()) { ListString matches = getMatches(resource.getInputStream(), pattern); String fileName = resource.getURI().getPath(); if (errorWhenFound) { if (!matches.isEmpty()) addError(fileName + : + matches); } else { if (matches.isEmpty()) addError(fileName); } } } } catch (IOException e) { addError(e.getMessage()); } } assertNoErrors(message); Martijn On Tue, Mar 2, 2010 at 12:56 PM, Sergey Olefir solf.li...@gmail.com wrote: Err, I guess I don't quite understand what you're proposing... My understanding is that I need to know all class names that are used by application as part of ResourceReference (and possibly something else too). How would I scan for that? Martijn Dashorst wrote: Create a unit test case that scans your application for resources and checks if the class is set. If not, fail. If set, check if it is unique, if not fail. Martijn -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to encrypt/obfuscate resource reference?
bgooren wrote: So I had a quick look at the source code of WebRequestCodingStrategy, and I think it should be possible to create a solution for your problem quite easily: Thanks to your idea, I played around with WebRequestCodingStrategy and below is what I came up with. It uses jasypt, but feel free to replace it with whatever you like more. package crypt.wicket; import java.util.Iterator; import java.util.Map; import java.util.Map.Entry; import java.util.concurrent.ConcurrentHashMap; import org.apache.wicket.Request; import org.apache.wicket.RequestCycle; import org.apache.wicket.protocol.http.request.WebRequestCodingStrategy; import org.apache.wicket.request.RequestParameters; import org.apache.wicket.request.target.resource.ISharedResourceRequestTarget; import org.apache.wicket.util.string.AppendingStringBuffer; import org.jasypt.encryption.pbe.StandardPBEStringEncryptor; import org.jasypt.salt.ZeroSaltGenerator; /** * Version of standard {...@link WebRequestCodingStrategy} that encrypts FQNs * (full qualified names of classes) in resource references. * * @author Sergey Olefir */ public class CryptWebRequestCodingStrategy extends WebRequestCodingStrategy { /** * Prefix for encrypted FQNs. */ public static final String ENCRYPTED_FQN_PREFIX = ---; /** * Map of unencrypted - encrypted strings. */ protected static final MapString, String toEncryptedMap = new ConcurrentHashMapString, String(); /** * Map of encrypted - unencrypted strings. */ protected static final MapString, String toUnencryptedMap = new ConcurrentHashMapString, String(); /** * Encrypted used to encrypt FQNs. */ private static final StandardPBEStringEncryptor encryptor; static { encryptor = new StandardPBEStringEncryptor(); encryptor.setAlgorithm(PBEWithMD5AndDES); encryptor.setSaltGenerator(new ZeroSaltGenerator()); // Need to use zero salt so that URLs are stable. encryptor.setStringOutputType(hexadecimal); // To avoid slashes in the result (base64 can produce slashes). encryptor.setPassword(your password here); } /* (non-Javadoc) * @see org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#addResourceParameters(org.apache.wicket.Request, org.apache.wicket.request.RequestParameters) */ @Override protected void addResourceParameters(Request request, RequestParameters parameters) { String pathInfo = request.getPath(); if (pathInfo != null pathInfo.startsWith(RESOURCES_PATH_PREFIX)) { int ix = RESOURCES_PATH_PREFIX.length(); if (pathInfo.length() ix) { StringBuffer path = new StringBuffer(pathInfo.substring(ix)); int ixSemiColon = path.indexOf(;); // strip off any jsession id if (ixSemiColon != -1) { int ixEnd = path.indexOf(?); if (ixEnd == -1) { ixEnd = path.length(); } path.delete(ixSemiColon, ixEnd); } // Check if we need to decrypt FQN. String pathString = path.toString(); if (pathString.startsWith(ENCRYPTED_FQN_PREFIX)) { if (pathString.length() ENCRYPTED_FQN_PREFIX.length()) { // Need to decrypt. pathString = pathString.substring(ENCRYPTED_FQN_PREFIX.length()); String head; String tail; int slash = pathString.indexOf('/'); if (slash 0) { head = pathString; tail = ; } else if (slash == 0) { head = ; tail = pathString; } else { head = pathString.substring(0, slash); tail = pathString.substring(slash); } // Do decrypt. pathString = decrypt(head) + tail; } } parameters.setResourceKey(pathString); } } } /* (non-Javadoc) * @see org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#encode(org.apache.wicket.RequestCycle, org.apache.wicket.request.target.resource.ISharedResourceRequestTarget) */ @SuppressWarnings(unchecked) @Override protected CharSequence encode(RequestCycle requestCycle,
Re: How to encrypt/obfuscate resource reference?
Good to know I contributed something useful to this thread haha. The code looks like the stuff I had in mind. You gotta love Wicket for making it quite easy to do this stuff; Although the URL encoding/decoding can be quite complex for beginners, but that is likely to be fixed in the future (I've had a look at Matej's wicket-ng implementation, and it looks very promising). Sergey Olefir wrote: Thanks to your idea, I played around with WebRequestCodingStrategy and below is what I came up with. It uses jasypt, but feel free to replace it with whatever you like more. -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27757852.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
Re: How to encrypt/obfuscate resource reference?
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
Re: How to encrypt/obfuscate resource reference?
He he, that was my old thread there :) Thing is, I just recently discovered, that encoding resources as arguments (rather than paths) completely breaks relative URLs discussed there: http://old.nabble.com/How-to-'resolve'-URL-in-stylesheet--td27720293.html (for the simple reason that browser strips out arguments when resolving relative url). So it is necessary to come up with some other solution. Antoine van Wel wrote: for a discussion and suggestion see http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27745911.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
Re: How to encrypt/obfuscate resource reference?
Oops :-) can't you just take the path and encrypt that using the same strategy as the cryptedurl.. thingy is using? Antoine On Mon, Mar 1, 2010 at 5:43 PM, Sergey Olefir solf.li...@gmail.com wrote: He he, that was my old thread there :) Thing is, I just recently discovered, that encoding resources as arguments (rather than paths) completely breaks relative URLs discussed there: http://old.nabble.com/How-to-'resolve'-URL-in-stylesheet--td27720293.html (for the simple reason that browser strips out arguments when resolving relative url). So it is necessary to come up with some other solution. Antoine van Wel wrote: for a discussion and suggestion see http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27745911.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 -- 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
Re: How to encrypt/obfuscate resource reference?
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. Sergey Olefir 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. -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27748507.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