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
