Second question, I'm wondering what the mentality of encoding stateless stuff is, at all. The CryptedUrlWebRequestCodingStrategy seems to use a session-id and random UUID combination to crypt the url. Doesn't this automatically make all stateless URLs stateful since they can't decrypt without the key from the session?
If so, how might I go about encrypting the URLs from my login page in such a way that it can't expire? On Mon, Mar 8, 2010 at 2:10 PM, Neil Curzon <[email protected]> wrote: > Hi users! > > I've been testing out the CryptedUrlWebRequestCodingStrategy for our wicket > app in 1.4.3 (yeah, soon to be upgraded..). We have two sites in Wicket. I > changed them both to use said CryptedUrlWebRequestCodingStrategy, and I > noticed that the login form post action only got encoded for one of them. > > I stepped through the code and noticed that the difference was that in one > of our apps (1), the Login page was set as the Home Page, and the Index page > was mounted at /home. In the other app (2), the Index page was set as the > Home Page, and the Login page was mounted at /login. In encode() in > CryptedUrlWebRequestCodingStrategy for (1), the call to encode() in the > wrapped defaultStrategy returns > ?wicket:bookmarkablePage=:com.acme.project.wicket.pages.section.FooLogin&wicket:interface=:1:loginForm::IFormSubmitListener:: > , and in (2) the call returns > login/wicket:interface/:2:componentId:loginForm::IFormSubmitListener:: . The > subsequent code then refuses to do any encoding unless there's a "?" in the > URL, which for (2), there isn't. > > Is this behavior intentional / necessary? It feels kinda fragile, and I'd > really rather not accidentally expose internals based on changing around > some bookmarkable links, or slightly reorganizing the app. Or, is there some > way to reliably force the URL for the (2) to have a "?" in it? > > Any help would be appreciated! > Thanks, > Neil >
