SHIRO-226. Contains proposal patch against current trunk and corresponding unit tests.
/janne On Dec 14, 2010, at 02:15 , Les Hazlewood wrote: > I don't see how having multiple cookies solves the data size problem. > In fact, I believe it makes the problem worse: instead of one cookie > header, now you have multiple, contributing to an even greater overall > request size. > > Also, if a user stores more than one principal in the collection > returned from a Realm, you can't just delete all but the primary > principal without the user's knowledge - they might not have a way to > reconstitute a Subject's identity properly - i.e. the primary > principal might have auxiliary information necessary when accessing > account data. You have to assume that if they provide multiple > principals, they actually need those to be retained for account lookup > later. > > My desire was to try to serialize the PrincipalCollection explicitly > and not delegate to the HashMap instance - as Janne suggested also. I > think if we do that, we may very well find that we don't have to > change anything because the data size will probably be within a > suitable range. > > It's certainly worth trying before we change anything else IMO. > > Les > > On Mon, Dec 13, 2010 at 3:02 PM, Kalle Korhonen > <[email protected]> wrote: >> On Mon, Dec 13, 2010 at 2:53 PM, Janne Jalkanen >> <[email protected]> wrote: >>> By using explicit serialization for things like realm names one should be >>> able to shave off a number of bytes *especially* for the very common >>> single-realm, single-principal case. It's a bit late over here, but I'll >>> try and see if I can generate some data or a patch tomorrow. >> >> Great. Using the primary principal and a cookie per realm would make >> this quite a bit more generic without loosing any of the benefits. >> >> Kalle >> >> >>> On Dec 13, 2010, at 22:25 , Les Hazlewood wrote: >>> >>>> I think it is a good use case, but I think we may not be on the same page >>>> yet. >>>> >>>> Unless I'm mistaken, the ID that Janne was talking about was a single >>>> user or account id in his own application. That corresponded to one >>>> principal in one realm only. I don't believe he was creating an ID >>>> that was a pointer to the PrincipalCollection instance, for example. >>>> >>>> So the question is: how do you efficiently represent a user's >>>> rememberMe identity when that identity could span multiple realms, or >>>> where there might be multiple principals, or a combination thereof? >>>> >>>> Are you implying that we create a RememberMeDAO to save the >>>> PrincipalCollection instance to a datastore (which will probably be >>>> fronted transparently with a cache) and send out the record's ID only >>>> in the cookie? That sounds like an extremely complicated solution >>>> since you'd have to come up with a purging strategy to handle orphan >>>> records - it's almost like solving the Session problem over again. >>>> >>>> My personal opinion is that I'd want to figure out a way to make the >>>> serialization output size more compact before going down that road. >>>> (It's something that should be done even if a DAO was used too). >>>> >>>> Regards, >>>> >>>> Les
