List Info

Thread: multiple sessions overwriting each others' data




multiple sessions overwriting each others' data
user name
2006-09-27 17:25:51
Hi Shane,

actually Turbine is doing it a bit different. Once a User
logs in, the 
User Object is stored within the session. And is made
accessible through 
RunData.getUser(); So the question really is, how do you
update the 
user? Through RunData.getUser().set...()? or through  
updates on the 
Database using TurbineSecurity? When the Logout occurs, the
following 
happens (from LogoutUser)
{
    User user = data.getUser();
     if (!TurbineSecurity.isAnonymousUser(user))
    {
        // Make sure that the user has really logged in.../
        if (!user.hasLoggedIn())
        {
            return;
        }
        user.setHasLoggedIn(Boolean.FALSE);
        TurbineSecurity.saveUser(user);
}

as you see, the object in the db will always be overwritten
with the 
user that is stored inside the session. I have implemented
something, 
that only allowed one user to be logged in at a given time.
If another 
user logs the second time, the first user is logged out
automatically. 
If you are interested I can provide the source.

Kind regards

Juergen Hoffmann

Shane Beasley schrieb:
>  Jürgen Hoffmann wrote:
>
> > Hi Shane,
>
>  Hi there. Thanks for replying!
>
> > How do you store the modifications the user has
made? Within the
> > Users temporary storage, or within a pull tool?
>
>  Actually, neither; I just added fields to the
TurbineUser object
>  itself. (This is a fairly simple webapp, and so I kept
the schema
>  simple, too.)
>
>  I realize that this is part of the problem, and
mentioned in the
>  previous message that one solution might be to
"refactor TurbineUser
>  to not have anything interesting in it."
>
>  However, this issue seems to be somewhat independent
of my situation.
>  For instance, consider where a user starts session X,
starts session
>  Y, changes his password in session Y, and leaves
session X to expire.
>  At that time, TorqueUserManager will then save the
unchanged
>  TurbineUser object from session X, and the password
would revert to
>  its original value, which I'm sure is a surprise to
the user. And, of
>  course, you can't just refactor the password out of
the TurbineUser
>  object. 
>
>  I hope that clarifies things a bit.
>
>  Shane
>
> 
------------------------------------------------------------
---------
>  To unsubscribe, e-mail: turbine-user-unsubscribejakarta.apache.org
>  For additional commands, e-mail: turbine-user-helpjakarta.apache.org
>
>
>  !EXCUBATOR:1,451a9a7953071159436427!


------------------------------------------------------------
---------
To unsubscribe, e-mail: turbine-user-unsubscribejakarta.apache.org
For additional commands, e-mail: turbine-user-helpjakarta.apache.org

multiple sessions overwriting each others' data
user name
2006-09-27 18:16:50
Jürgen Hoffmann wrote:

>  So the question really is, how do you update the user?
Through
>  RunData.getUser().set...()?

For better or worse, I learned Turbine/Torque by reading
code from 
another project by another developer. It operated directly
upon the 
TurbineUser object by means of the following method:

    public static TurbineUser getTurbineUser(RunData data) {
        return 
(TurbineUser)((TorqueUser)(data.getUser())).getPersistentObj
();
    }

Based on my experience, I get the feeling that there's
something better, 
but I don't know what that is, so I've stuck with the status
quo.

How do other people do this sort of thing? I can imagine
using 
RunData.getUser().getPerm/setPerm instead, although our
current design 
allows us to use foreign keys to build relationships between
TurbineUser 
and other tables/objects, whereas I don't think
getPerm/setPerm would do 
the same.

>  as you see, the object in the db will always be
overwritten with the
>  user that is stored inside the session.

Yep, that's what's happening. Your sample code comes from
the LogoutUser 
action, which defers to TurbineSecurity.saveUser, which
defers to 
TurbineSecurityService.saveUser, which defers to 
TorqueUserManager.store. As a consequence of that, I can
also provide my 
own user manager that does something different for 
TorqueUserManager.store (e.g. make *that* a no-op), except I
don't know 
what else will break if I do that. 

>  I have implemented something, that only allowed one
user to be logged
>  in at a given time. If another user logs the second
time, the first
>  user is logged out automatically. If you are
interested I can
>  provide the source.

Actually, I would like to see that code, if it's not a
bother... Thanks 
again!

Shane

------------------------------------------------------------
---------
To unsubscribe, e-mail: turbine-user-unsubscribejakarta.apache.org
For additional commands, e-mail: turbine-user-helpjakarta.apache.org

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )