On Thu, Nov 15, 2012 at 12:37 AM, Mark Struberg <[email protected]> wrote: >> 1. Small key size used to store views into session vs go back to the old way. > > Take a safe approach. Adding just the hashCode doesn't make it more safe. > Either the full viewId or get rid of it completely if not needed.
>> 2. use the hashCode of the viewId vs store the full viewId and do an >> equals comparison vs remove it from the key. > IF the viewId is important than we must do the equals on the viewId in > addition. Well, the hashcode doesn't make it perfectly safe, but it certainly makes it more safe. The real question is what are we safe-guarding against? A bug in our code? Or is there some other way that the counter could be corrupted? Is this a check to insure that the response didn't get corrupted? I've certainly experienced response corruption due to exceptions during page generation as well as proxy servers that truncate total form submission length, and checks against this are valuable to me. If we are checking against possible corruption, then this check doesn't have to be perfect, just like an md5 checksum on a downloaded file doesn't perfectly guarantee that you are getting back the same file However, hashcode for classes not under our control don't guarantee useful checksums across various JVMs. The hashcode could be zero for all values. But in reality, is this likely to be true? I would imagine that any String hashcode would be valid as a checksum. Mark, you said there were issues with IBM's JVM hashcodes. Can you summarize what those would be in this specific situation? For my limited understanding of this topic, I'd say that we either drop all but the counter, or, if this is some kind of corrupted data check, that we only use a checksum value rather than the full viewID. On Wed, Nov 14, 2012 at 8:17 PM, Leonardo Uribe <[email protected]> wrote: > 1. In MYFACES-3568, the following private internal classes extending from > an abstract class called SerializedViewKey: > > - IntIntSerializedViewKey > - IntByteArraySerializedViewKey > - ReferenceSerializedViewKey > > The idea is serialize an Object is more expensive than serialize a > primitive type. > So, using IntIntSerializedViewKey and IntByteArraySerializedViewKey in > production stage will lead to a smaller session size compared to use the old > implementation of SerializedViewKey, with requires to store the full viewId. I'm confused about this one. Can you provide more information? Why do we need more than one way to do it? Why wouldn't we pick the most efficient method and use it in both production and development? On Wed, Nov 14, 2012 at 8:17 PM, Leonardo Uribe <[email protected]> wrote: > the current design using private static classes > ensures that it is not possible to create keys outside the algorithm > and override > the values inside the internal map that holds the view state. For example, > with > Java 2 security it is possible to ensure that code cannot be executed > using reflection > and so on. Putting the classes outside the class makes harder to control that. I'm also confused about this one. Can you provide more information? What security problem are we trying to prevent? The developer from creatiing their own key algorithm?
