You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Paul Nicolucci <pn...@us.ibm.com> on 2018/01/27 23:17:43 UTC
MyFaces 2.3.0 last item - MyFaces-4133
Hi,
It looks like the only remaining item we have before we can deliver 2.3.0
is : https://issues.apache.org/jira/browse/MYFACES-4133
@Leonardo/Thomas, has an acceptable fix been created? Can we deliver 2.3.0
without a fix or is this mandatory?
Thanks,
Paul
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Thomas Andraschko <an...@gmail.com>.
Commited a newer version of the patch, which doesn't remove the
StateTokenProcessor, but introduced a second implementation which will be
instantiated by the StateCache.
2018-01-29 19:59 GMT+01:00 Thomas Andraschko <an...@gmail.com>:
> Thanks Leo.
> As it said, it would be great if you could refactor it later but it's the
> time right to change this behavior and i would like to see a release soon.
>
> 2018-01-29 15:28 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
>
>> Hi
>>
>> Ok, Before 2.3.0 release is the right time to do it. I do not want to be
>> a stone on the road, so please do it. I think I have made clear my
>> reasoning about it, it is not mandatory, it is just an opinion.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2018-01-29 3:52 GMT-05:00 Thomas Andraschko <an...@gmail.com>
>> :
>>
>>> Hi,
>>>
>>> the question is: Why should we use encryption and serialization when
>>> it's actually >NOT< required for server side state?
>>> Sure, encryption should be safe actually but instead of using a better
>>> encryption algorithm like mentioned in the ticket, it's better to just
>>> removed the encryption.
>>> Probably it's also better for performance reasons - however i think it's
>>> not measurable.
>>>
>>> IMO the best solution would be the following:
>>> 1) skip serialization on server-side state
>>> 2) upgrade to algorithm, like also mentioned in the ticket, for client
>>> side state
>>>
>>> So we are safer for client side state and absolutely safe for server
>>> side state.
>>>
>>> Also the community is interessted in doing the change. The TomEE guys
>>> already forked MyFaces do to this changes in 2.2.x AFAIR.
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>> 2018-01-29 3:07 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> I think this issue has very low priority. After thinking a lot on it I
>>>> prefer do not do nothing. Less is more in my opinion.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu...@gmail.com>:
>>>>
>>>>> Hi
>>>>>
>>>>> I think MYFACES-4133 does not qualify to be a bug, because encryption
>>>>> should be always enabled.
>>>>>
>>>>> Is it required? No
>>>>>
>>>>> Is it an improvement? Not really. I still need a reason why enable
>>>>> this mode.
>>>>>
>>>>> Can we avoid the serialization/deserialization step? yes.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <
>>>>> andraschko.thomas@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> IMO the change is almost mandatory for 2.3.0.
>>>>>>
>>>>>> Please also see the discussion in "[myfaces core] don't deserialize
>>>>>> ViewState-ID if state saving method is server".
>>>>>>
>>>>>> @Leo: Do you have time to refactor it?
>>>>>>
>>>>>> Otherwise i would reapply my patch but with "random" instead of
>>>>>> "secureRandom".
>>>>>> Thats fine for now. We can still refactor or improve the API later in
>>>>>> 2.3.x or even in JSF.next.
>>>>>>
>>>>>> Regards,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It looks like the only remaining item we have before we can deliver
>>>>>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>>>>>
>>>>>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>>>>>> 2.3.0 without a fix or is this mandatory?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Thomas Andraschko <an...@gmail.com>.
Thanks Leo.
As it said, it would be great if you could refactor it later but it's the
time right to change this behavior and i would like to see a release soon.
2018-01-29 15:28 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> Ok, Before 2.3.0 release is the right time to do it. I do not want to be a
> stone on the road, so please do it. I think I have made clear my reasoning
> about it, it is not mandatory, it is just an opinion.
>
> regards,
>
> Leonardo Uribe
>
>
> 2018-01-29 3:52 GMT-05:00 Thomas Andraschko <an...@gmail.com>:
>
>> Hi,
>>
>> the question is: Why should we use encryption and serialization when it's
>> actually >NOT< required for server side state?
>> Sure, encryption should be safe actually but instead of using a better
>> encryption algorithm like mentioned in the ticket, it's better to just
>> removed the encryption.
>> Probably it's also better for performance reasons - however i think it's
>> not measurable.
>>
>> IMO the best solution would be the following:
>> 1) skip serialization on server-side state
>> 2) upgrade to algorithm, like also mentioned in the ticket, for client
>> side state
>>
>> So we are safer for client side state and absolutely safe for server side
>> state.
>>
>> Also the community is interessted in doing the change. The TomEE guys
>> already forked MyFaces do to this changes in 2.2.x AFAIR.
>>
>> Regards,
>> Thomas
>>
>>
>>
>> 2018-01-29 3:07 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> Hi
>>>
>>> I think this issue has very low priority. After thinking a lot on it I
>>> prefer do not do nothing. Less is more in my opinion.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> I think MYFACES-4133 does not qualify to be a bug, because encryption
>>>> should be always enabled.
>>>>
>>>> Is it required? No
>>>>
>>>> Is it an improvement? Not really. I still need a reason why enable this
>>>> mode.
>>>>
>>>> Can we avoid the serialization/deserialization step? yes.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <
>>>> andraschko.thomas@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> IMO the change is almost mandatory for 2.3.0.
>>>>>
>>>>> Please also see the discussion in "[myfaces core] don't deserialize
>>>>> ViewState-ID if state saving method is server".
>>>>>
>>>>> @Leo: Do you have time to refactor it?
>>>>>
>>>>> Otherwise i would reapply my patch but with "random" instead of
>>>>> "secureRandom".
>>>>> Thats fine for now. We can still refactor or improve the API later in
>>>>> 2.3.x or even in JSF.next.
>>>>>
>>>>> Regards,
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It looks like the only remaining item we have before we can deliver
>>>>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>>>>
>>>>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>>>>> 2.3.0 without a fix or is this mandatory?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Ok, Before 2.3.0 release is the right time to do it. I do not want to be a
stone on the road, so please do it. I think I have made clear my reasoning
about it, it is not mandatory, it is just an opinion.
regards,
Leonardo Uribe
2018-01-29 3:52 GMT-05:00 Thomas Andraschko <an...@gmail.com>:
> Hi,
>
> the question is: Why should we use encryption and serialization when it's
> actually >NOT< required for server side state?
> Sure, encryption should be safe actually but instead of using a better
> encryption algorithm like mentioned in the ticket, it's better to just
> removed the encryption.
> Probably it's also better for performance reasons - however i think it's
> not measurable.
>
> IMO the best solution would be the following:
> 1) skip serialization on server-side state
> 2) upgrade to algorithm, like also mentioned in the ticket, for client
> side state
>
> So we are safer for client side state and absolutely safe for server side
> state.
>
> Also the community is interessted in doing the change. The TomEE guys
> already forked MyFaces do to this changes in 2.2.x AFAIR.
>
> Regards,
> Thomas
>
>
>
> 2018-01-29 3:07 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
>
>> Hi
>>
>> I think this issue has very low priority. After thinking a lot on it I
>> prefer do not do nothing. Less is more in my opinion.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> Hi
>>>
>>> I think MYFACES-4133 does not qualify to be a bug, because encryption
>>> should be always enabled.
>>>
>>> Is it required? No
>>>
>>> Is it an improvement? Not really. I still need a reason why enable this
>>> mode.
>>>
>>> Can we avoid the serialization/deserialization step? yes.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <andraschko.thomas@gmail.com
>>> >:
>>>
>>>> Hi,
>>>>
>>>> IMO the change is almost mandatory for 2.3.0.
>>>>
>>>> Please also see the discussion in "[myfaces core] don't deserialize
>>>> ViewState-ID if state saving method is server".
>>>>
>>>> @Leo: Do you have time to refactor it?
>>>>
>>>> Otherwise i would reapply my patch but with "random" instead of
>>>> "secureRandom".
>>>> Thats fine for now. We can still refactor or improve the API later in
>>>> 2.3.x or even in JSF.next.
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> It looks like the only remaining item we have before we can deliver
>>>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>>>
>>>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>>>> 2.3.0 without a fix or is this mandatory?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Paul
>>>>>
>>>>
>>>>
>>>
>>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Thomas Andraschko <an...@gmail.com>.
Hi,
the question is: Why should we use encryption and serialization when it's
actually >NOT< required for server side state?
Sure, encryption should be safe actually but instead of using a better
encryption algorithm like mentioned in the ticket, it's better to just
removed the encryption.
Probably it's also better for performance reasons - however i think it's
not measurable.
IMO the best solution would be the following:
1) skip serialization on server-side state
2) upgrade to algorithm, like also mentioned in the ticket, for client side
state
So we are safer for client side state and absolutely safe for server side
state.
Also the community is interessted in doing the change. The TomEE guys
already forked MyFaces do to this changes in 2.2.x AFAIR.
Regards,
Thomas
2018-01-29 3:07 GMT+01:00 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> I think this issue has very low priority. After thinking a lot on it I
> prefer do not do nothing. Less is more in my opinion.
>
> regards,
>
> Leonardo Uribe
>
> 2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu...@gmail.com>:
>
>> Hi
>>
>> I think MYFACES-4133 does not qualify to be a bug, because encryption
>> should be always enabled.
>>
>> Is it required? No
>>
>> Is it an improvement? Not really. I still need a reason why enable this
>> mode.
>>
>> Can we avoid the serialization/deserialization step? yes.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <an...@gmail.com>
>> :
>>
>>> Hi,
>>>
>>> IMO the change is almost mandatory for 2.3.0.
>>>
>>> Please also see the discussion in "[myfaces core] don't deserialize
>>> ViewState-ID if state saving method is server".
>>>
>>> @Leo: Do you have time to refactor it?
>>>
>>> Otherwise i would reapply my patch but with "random" instead of
>>> "secureRandom".
>>> Thats fine for now. We can still refactor or improve the API later in
>>> 2.3.x or even in JSF.next.
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>
>>>> Hi,
>>>>
>>>> It looks like the only remaining item we have before we can deliver
>>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>>
>>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>>> 2.3.0 without a fix or is this mandatory?
>>>>
>>>> Thanks,
>>>>
>>>> Paul
>>>>
>>>
>>>
>>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I think this issue has very low priority. After thinking a lot on it I
prefer do not do nothing. Less is more in my opinion.
regards,
Leonardo Uribe
2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> I think MYFACES-4133 does not qualify to be a bug, because encryption
> should be always enabled.
>
> Is it required? No
>
> Is it an improvement? Not really. I still need a reason why enable this
> mode.
>
> Can we avoid the serialization/deserialization step? yes.
>
> regards,
>
> Leonardo Uribe
>
> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <an...@gmail.com>:
>
>> Hi,
>>
>> IMO the change is almost mandatory for 2.3.0.
>>
>> Please also see the discussion in "[myfaces core] don't deserialize
>> ViewState-ID if state saving method is server".
>>
>> @Leo: Do you have time to refactor it?
>>
>> Otherwise i would reapply my patch but with "random" instead of
>> "secureRandom".
>> Thats fine for now. We can still refactor or improve the API later in
>> 2.3.x or even in JSF.next.
>>
>> Regards,
>> Thomas
>>
>>
>>
>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>>
>>> Hi,
>>>
>>> It looks like the only remaining item we have before we can deliver
>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>
>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>> 2.3.0 without a fix or is this mandatory?
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>
>>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I think MYFACES-4133 does not qualify to be a bug, because encryption
should be always enabled.
Is it required? No
Is it an improvement? Not really. I still need a reason why enable this
mode.
Can we avoid the serialization/deserialization step? yes.
regards,
Leonardo Uribe
2018-01-28 9:12 GMT-05:00 Thomas Andraschko <an...@gmail.com>:
> Hi,
>
> IMO the change is almost mandatory for 2.3.0.
>
> Please also see the discussion in "[myfaces core] don't deserialize
> ViewState-ID if state saving method is server".
>
> @Leo: Do you have time to refactor it?
>
> Otherwise i would reapply my patch but with "random" instead of
> "secureRandom".
> Thats fine for now. We can still refactor or improve the API later in
> 2.3.x or even in JSF.next.
>
> Regards,
> Thomas
>
>
>
> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
>
>> Hi,
>>
>> It looks like the only remaining item we have before we can deliver 2.3.0
>> is : https://issues.apache.org/jira/browse/MYFACES-4133
>>
>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>> 2.3.0 without a fix or is this mandatory?
>>
>> Thanks,
>>
>> Paul
>>
>
>
Re: MyFaces 2.3.0 last item - MyFaces-4133
Posted by Thomas Andraschko <an...@gmail.com>.
Hi,
IMO the change is almost mandatory for 2.3.0.
Please also see the discussion in "[myfaces core] don't deserialize
ViewState-ID if state saving method is server".
@Leo: Do you have time to refactor it?
Otherwise i would reapply my patch but with "random" instead of
"secureRandom".
Thats fine for now. We can still refactor or improve the API later in 2.3.x
or even in JSF.next.
Regards,
Thomas
2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pn...@us.ibm.com>:
> Hi,
>
> It looks like the only remaining item we have before we can deliver 2.3.0
> is : https://issues.apache.org/jira/browse/MYFACES-4133
>
> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver 2.3.0
> without a fix or is this mandatory?
>
> Thanks,
>
> Paul
>