Jon committed a couple of days ago some code (which he mentioned is not ready for production yet) regarding obfuscating wicket querystrings. The approach Jon has choosen is to add /secure to the url path and have the querystring encrypted. URLs will than look like /signin2/secure?AG56HSA76S.As you can see from the URL I choose the SignIn2 example for playing around. Soon it became clear that adding /secure to the path breaks all relative links like in <link rel="stylesheet" type="text/css" href="style.css"/>. The container is/will not be able to find style.css. I can think of at least two solutions: a) make that link a wicket-component and dynamically change the href as needed and b) change the obfuscating code. I choose to have a deeper look into the obfuscating code and I have a couple of changes in mind.
I'd prefer to have a more flexible approach which allows to easily replace the obfuscating alogrithm and thus to avoid problems like the one mentioned above. Alternative obfuscating algorithms could be like /signin2?secure=AGFG576GF or even allow extra parameters like /signin2?secure=AGFG576GF&id=123 or /signin2/secure/AGFG576GF (a path and no parameter). Instead of having the obfuscating code in RequestCycle and Response which are deep-core classes, I'd prefer to have something like WebResponseWithCryptedUrl and WebRequestwithCryptedUrl. I'd prefer to have it as less as possible mixed with deep-core classes. Juergen ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
