Great to hear!

The purpose of the encryption is to prevent the reverse engineering of
the view state. If you use an encryption method which is good enough,
you should not have any problems.

The problem with this reverse engineering of the view state is that -
as you mentioned - there could be login data or some other sort of
critical data saved in the state. Before JSF 2.0, the view state only
contained the state of all components, but unfortunately in JSF 2.0
also all @ViewScoped beans are stored in this state, which makes it
more likely that critical data is stored in it. And of course, you
don't want anyone else then the user to see this.

Regards,
Jakob

2010/12/11 ken keller <[email protected]>:
> I disabled encryption (see below), redeployed, & everything works--seemingly
> it is much more responsive too.
>
> What's the purpose of the encryption? When I View Source, ViewState field
> looks like a long, hex string. Even if it can be reverse-engineered, the
> values are likely to be the same ones sent in the http request. These are
> vulnerable to MITM attack unless one uses https. Is JSF smart enough to
> exclude a password field's value from ViewState?
>
> <context-param>
>        <param-name>org.apache.myfaces.USE_ENCRYPTION</param-name>
>        <param-value>false</param-value>
>     </context-param>
>
>  <context-param>
>    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>    <param-value>client</param-value>
>  </context-param>
>
> On Fri, Dec 10, 2010 at 2:40 PM, Leonardo Uribe <[email protected]> wrote:
>
>> Hi
>>
>> One last note, to make client side state saving work try configure this two
>> params:
>>
>>
>> org.apache.myfaces.SECRET
>>
>> org.apache.myfaces.MAC_SECRET
>>
>>
>> It is probably that the ViewExpiredException is thrown because you are not
>> configured the mac secret.
>>
>> See http://wiki.apache.org/myfaces/Secure_Your_Application  for details.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2010/12/10 Leonardo Uribe <[email protected]>
>>
>> > Hi
>> >
>> > Is there any way to see the app log? In theory, when a
>> ViewExpiredException
>> > is thrown, the reason is logged there, but there is not on the browser.
>> >
>> >
>> > I readed your previous emails related to this one and one possibility
>> that
>> > comes to my mind is we are storing something on session without implement
>> > Serializable interface. If that so, as soon as GAE serialize the session
>> to
>> > disk, that code causes an Exception and when MyFaces try to restore the
>> > state it just has dissapeared (servlet session is invalid, so a new one
>> is
>> > created and our value in javax.faces.ViewState request parameter is not
>> > found, so a ViewExpiredException is thrown).
>> >
>> > The solution if that is the case is check all lines that do something
>> with
>> > session map and check if it is possible to serialize to disk.
>> >
>> > regards,
>> >
>> > Leonardo
>> >
>>
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Reply via email to