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 <andraschko.tho...@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 <lu4...@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 <andraschko.tho...@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 <lu4...@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 <lu4...@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.tho...@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 <pnico...@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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
