I remember reading a lot of talk in the tapestry-users list about security and client state as well.
In a completely off-the-cuff thought sort of way I can see a few options here: 1) Provide a system/hivemind/whatever configurable property that specifies the sort of encrytion scheme you'd like to use on these states...Could be none/base64/blowfish/md5/sha/etc....Then only people who need it have to take the performance hit. 2) Provide a general guideline on how some of these things should be done. For instance, it should be acceptable to say that a users identity will always be stored in the servers session. Then, it doesn't really matter what client-side data people are able to intercept/parse because they won't be able to do anything with it unless their previously identified user has the correct permissions. Of course #2 would then imply that you have built-in runtime checks for permissions, not just exclusionary ones that do/don't display links and such. I have one such runtime/hivemind binding/etc implementation that I could make publicly available, if I could find someone who'd be willing to maintain it ;) > > > When a form is triggered, it will no longer render itself; instead it > > will use the serialized stream to perform callbacks that reflect the > > order in which the fields rendered in the first place. > > Have you thought about security implication? Just a guess... >
