Simon Kitching-3 wrote: > > Yep. That's why there is an option to encrypt the client-side state. > > However in general it's not necessary; all the user can do is stuff up > their own use of the app. Remember that all JSF does is pass data > through to managed beans that then implement the business logic; that > java code should only allow users to perform valid operations. >
What about their ability to mess with converters and validators? I'm sure the managed beans would have some assumptions about the data passed in to them based on the converters and validators and other things used. Are these also serialized to the client? > The controller tree state is stored in the user's http session. > > A hidden field is needed in the page in order to ensure that when a user > clicks the "back" button, or runs multiple windows in parallel, that the > right controller state is pulled from the user's http session; myfaces > keeps the last N controller trees in the session where N is configurable > precisely in order to support back buttons when using server-side state. > Sorry, what do you mean by "controller" tree state? Did you mean component? Could you please expand on this back button issue? I'm sure it's not just the fact that you're viewing an outdated page that hasn't been refreshed with the most current data (as I'm guessing that could be simply solved by setting the page to not be cached.) Is it similar to the issue with, for example, online banking, where you click the back button and it gives a browser error? What is the back button issue, and how does JSF help to resolve it? Thanks. -- View this message in context: http://www.nabble.com/Understanding-JSF-MyFaces-tf2782475.html#a7765488 Sent from the MyFaces - Users mailing list archive at Nabble.com.
