Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of gcjmu-myfaces-user@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: users@myfaces.apache.org
From: Werner Punz <werner.punz@gmail.com>
Subject: Re: java.io.InvalidObjectException: enum constant attributes does
 not exist in class javax.faces.component.UIComponent$PropertyKeys
Date: Sun, 12 Dec 2010 11:45:30 +0100
Lines: 101
Message-ID: <ie294b$ohq$1@dough.gmane.org>
References: <AANLkTimn6Ti8YWLtWMHgf-=R4pb9et3_Zw+7wJKPTYBK@mail.gmail.com>
 <AANLkTimZOwQqiR+T9DCYRcwfnzkHqee6iq2TBOxRBzhR@mail.gmail.com>
 <idrb7n$2cs$2@dough.gmane.org> <idrbfp$2cs$3@dough.gmane.org>
 <idrdnf$guo$1@dough.gmane.org>
 <AANLkTi=jUmRhyv0xoesc+PZDt-FsLi_wrqBH5GDptEy7@mail.gmail.com>
 <idrjrt$fm2$1@dough.gmane.org> <idrq0h$cqb$1@dough.gmane.org>
 <idrt3c$p9d$1@dough.gmane.org> <idru52$t8t$1@dough.gmane.org>
 <AANLkTinCgUFMGdCbPxCfPitgH-wwniX972bNALOrq1Ga@mail.gmail.com>
 <idsogr$pnt$1@dough.gmane.org> <idsqd6$24a$1@dough.gmane.org>
 <idsrd4$6ci$2@dough.gmane.org>
 <AANLkTimndnYU81aQ1gtvhh8wXFny41W_fKgdr2ySuy1Y@mail.gmail.com>
 <AANLkTinxE2qiTZLgO6vCzif9u7JpyLzxFreCkok6xs3p@mail.gmail.com>
 <AANLkTims73VPzC=19NXkrq-p=bUrxM1DP0wrkxxthd6h@mail.gmail.com>
 <AANLkTimgQKF8mJ0-zkc8D66ZdpBfBSbcGYS dG-q7D27S@mail.gmail.com>
 <ie28nq$ms4$1@dough.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
In-Reply-To: <ie28nq$ms4$1@dough.gmane.org>

Btw. generally server side state saving is way faster than client side, 
although the difference has been somewhat reduced thanks to delta state 
saving. The reason simply is you transmit way less data over the line 
with the server side state saving on.

Werner


Am 12.12.10 11:38, schrieb Werner Punz:
> Hi Ken die purpose of the encryption is a security problem, if you do
> not encrypt the viewstate on the client side then it is reverse
> engineerable from a third party.
> We had to introduce that to fix that hole.
> For server side state saving the encryption is not really needed unless
> you do not trust the third party you host the state with.
>
>
> Werner
>
>
> Am 11.12.10 00:31, schrieb ken keller:
>> 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<lu4242@gmail.com> 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<lu4242@gmail.com>
>>>
>>>> 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
>>>>
>>>
>>
>
>
>