On 13/10/2014 09:52, Martin Grigorov wrote:
Hi Jesse,
Thanks for identifying these problems and working on the improvements!
I've added some comments about small issues to
https://github.com/apache/wicket/commit/c63989018a8fb11a3dbbc68253e74f3fd2117430
.
I like the new setting used for the new "crypt." prefix used for the page
expired notification.
Is it good idea to use such settings/flags to be able to tell what to be
encrypted (componentAndPageInfo, query strings, all) explicitly ? At the
moment this is "calculated".
I ask whether it is sensible to keep the current code that decides what to
encrypt and what not and add settings which will define this explicitly ?
Hi Martin,
Thank you for your valuable feedback.
"OK, will do" on all your inline comments.
RE: Settings for what to encrypt:
How about protected boolean shouldEncryptEntireUrl(Url url)?
true -> entire url.
false -> pageComponentInfo query param.
I dont think we should try to encrypt all query parameters. Sometimes
query parameters are for state and should be encrypted, but Wicket has
much better built in state management that does not expose itself in URL.
Other query parameters should be editable by the user, like Google "q",
and we would lose this ability.
Also, we will always have unencrypted query parameters coming in, user
modifies URL, Ajax additional params etc. When URL is manually edited,
we would get needless redirects, like
/mypage?wicket=encrypted&additional=param redirect to
/mypage?wicket=LongerEncryptedThing.
What happens when a user manually adds an unencrypted param that exists
with a different value in the encrypted part?
Thanks,
Jesse
