lightbulb432 wrote:
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?
Hmm, good point. When unencrypted client-side state saving is done, I
guess the returned component tree could be altered by the client to
remove validator objects from components. Data from the component would
then be pushed into the model where it would normally trigger a
validation error.
It wouldn't be trivial, as the data is base-64 encoded and of a format
specific to the JSF implementation (and probably version too). However
it's possible for a sufficiently determined user.
So for security-sensitive sites, don't use unencrypted client-side state.
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?
Yes, sorry.
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?
It's only a problem when using server-side state. User posts data [1] to
pageX.jsf, which forwards to pageY. The component tree for pageY is
built and stored in the user's session and the rendered page is sent to
the user. They press the back button, causing the original data at [1]
to be posted to pageX.jsf. If the JSF implementation pulls the "current
component tree" out of the user session (the pageY component tree) and
tries to use that to process the submitted data, problems will occur.
This was fixed a year or two ago, by keeping a set of old component
trees in the session and having a token in the page to indicate which
one should be used.
There is no problem when using client-side state for obvious reasons.
Regards,
Simon
