Yeah, and who says there needs to be exactly one cookie for this. What if there was one cookie per realm? Named rememberMe_<realmName> for example. Iterating over the cookies is simple. It would probably make more sense to expire rememberme cookies by realm anyway.
Kalle On Mon, Dec 13, 2010 at 2:53 PM, Janne Jalkanen <[email protected]> wrote: > > Yes, my ID is an UUID which is used to access the DB directly. It is wrapped > in an User object, which can then lazily fetch the rest of its contents from > the DB (and stores them internally in transient fields to avoid their > serialization). > > My proposal would be to skip the HashMap serialization and use something like > > out.writeShort( principalCollection.length() ); > > for( Object p : principalCollection ) { > out.writeUTF( realmName ); > out.writeObject( p ); // Just use default serialization here; otherwise a > bit complicated > } > > 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. > > /Janne > > 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 > >
