> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 07, 2003 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Discussion on TTWS30 - Session unbind causes
> TURBINE_USER to be updated
>
>
> >This happens on logout (because the anonymous user replaces the
> >authenticated one on the session) and session timeout.
>
> >We have the following cases:
>
> >1. The user does not log out and the session timesout.
> > Current: The entire user object is written to the database
> > Proposed change: Only last login date, access counter, and
> >persistent pull tools would be saved
>
> So the LogoutAction should call a "DisposeUser" or
> "putAuthenticatedUser" method in the SecurityService to
> return the User object to the service. Think of it as ending
> the life cycle of the user object. Its factory (which is the
> SecurityService that returned it from getAuthenticatedUser())
> should dispose it.
>
> Doing this in a completely different Service is IMHO at least
> a layer violation. And your Session Service has no idea
> whether the object is writeable at all.
>
The SessionService is a completely different topic. It is not involved
in this at all.
TurbineUser currently implements the HttpSessionBindingListener
interface. Because of this, when this object is removed from a
HttpSession object, the valueUnbound(HttpSessionBindingEvent) method is
executed. This method, in turn, calls the security service to save the
user to the persistent store. It all happens in the correct layer.
I propose to add a new method to the security service that will save
just the last login, access counter, and persistent pull tools. This
would be called during the execution of the
valueUnbound(HttpSessionBindingEvent) method in TurbineUser instead of
TurbineSecurity.saveOnSessionUnbind(this).
>
> >2. The user logs out. Session timesout later.
> > Current: Although the Logout Action appears to be written to save
> >the user object, it doesn't. The user is not in RunData when the
> >Logout
>
> That's IMHO a bug.
>
Probabley so. No one ever noticed it because the user does get saved...
Just not there.
> >action executes. This becomes the same use case as #1
>
> It is not? Where is it? It should be there. Are you sure about this?
>
Completely. I stepped through it with a debugger as I was writing the
previous response. The user is put into RunData by the session
validator. This will execute AFTER the logout action. The LogoutUser
action containes the following code:
User user = data.getUser();
if (user != null)
{
// Make sure that the user has really logged in...
if (!user.hasLoggedIn())
{
return;
}
user.setHasLoggedIn(new Boolean(false));
TurbineSecurity.saveUser(user);
}
Since data.getUser() will return null, the user is not saved.
> > Proposed change: Same as #1.
>
> No. Fixing the Logout Action is the correct change.
>
I think that the code which is never executed should be removed. I
don't think that the Logout Action should call
TurbineSecurity.save(user) though. Just because the user logs out is no
reason to write the entire user object to the persistent store.
Let's say that the an application updates the user object to change the
user's login name. At this point, the version in the session and the
version on the persistent storage are out of sync. The change should be
written to the persistent store by either calling user.save() (which
would seem like the correct method to call) or
TurbineSecurity.saveUser(user). If that does not happen, those changes
should never be written to the persisent storage! The way the code is
currently written, the change will be written when the user object is
removed from the session.
> >This brings up the obvious question. How are changes made to the
> >cached user object going to be saved? They aren't. If
> changes need to
> >be made to the user object, the security service should be called to
> >write the updates.
>
> Yep. Did you get my mail about the Password changes?
No, I guess I missed that. I will go back through the messages...
>
> Regards
> Henning
>
>
> >> -----Original Message-----
> >> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]]
> >> Sent: Tuesday, January 07, 2003 6:19 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Discussion on TTWS30 - Session unbind causes
> >> TURBINE_USER to be updated
> >>
> >>
> >> "Quinton McCombs" <[EMAIL PROTECTED]> writes:
> >>
> >> >I have implemented the fix mentioned in the previous
> >> message. There is
> >> >one small difference...
> >>
> >> >I ended up saving everything that would be serialized into the
> >> >OBJECT_DATA column on session unbind. This could pose a *small*
> >> >problem for anyone using the permData hashtable for
> storage of extra
> >> >data.
> >>
> >> >If no one objects to this, I will commit the changes in
> the next few
> >> >days.
> >>
> >> Quinton,
> >>
> >> I was thinking about your statement and while I might not
> >> having gotten exactly the point, please note one thing I fell
> >> into headfirst a while ago:
> >>
> >> "The lifetime of a Turbine Session (and connected with
> >> it the lifetime of the User object) differs from the
> >> lifetime of a Servlet Session!"
> >>
> >> Please make this a mantra you repeat every time you work on
> >> session management. I had to. :-)
> >>
> >>
> >> Look:
> >>
> >> ---> -------------------------> time
> -------------------------> --->
> >> | | | |
> >> Servlet Session bind | |
> Session unbind
> >> | | | |
> >> | | | |
> >> v | | v
> >> Bind Event | |
> Unbind event
> >> | | | |
> >> v | | v
> >> Turbine inits an | |
> Session expires
> >> anonymous user object | |
> >> v v
> >> Login -> Turbine creates -> Logout
> >> an authenticated
> >> user object
> >>
> >> So neither the (container provided) session binding event nor
> >> session unbinding have actually anything in common with the
> >> lifetime of the Turbine User object (though if the user does
> >> not log out but lets his session expire, these events match.
> >> But this is nothing you can really rely on)!
> >>
> >> I'm quite scared if you move User object related
> >> serialization into Session related events. These don't match.
> >> What if an user logs out and logs on again in the same
> >> session as another user? What if an user logs out (destroys
> >> the user object) and the session expires some ten minutes later?
> >>
> >> The session information is nice for "knowing how many current
> >> sessions are running and who logged on". But for nothing much
> >> else, unless we redefine the session management
> >> (SessionValidator, AccessController (Trust me, we won't)).
> >>
> >> Regards
> >> Henning
> >>
> >> --
> >> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --
> >> Geschaeftsfuehrer
> >> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
> [EMAIL PROTECTED]
> >>
> >> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
> >> D-91054 Buckenhof Fax.: 09131 / 50654-20
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:turbine-dev-> [EMAIL PROTECTED]>
> >> For
> >> additional commands,
> >> e-mail: <mailto:[EMAIL PROTECTED]>
> >>
> >>
>
> >--
> >To unsubscribe, e-mail:
> <mailto:turbine-dev-> [EMAIL PROTECTED]>
> >For
> additional commands,
> e-mail:
> ><mailto:[EMAIL PROTECTED]>
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --
> Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> --
> To unsubscribe, e-mail:
> <mailto:turbine-dev-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
