> -----Original Message-----
> From: Aurelien Pernoud [mailto:apernoud@;sopragroup.com]
> Sent: Tuesday, November 12, 2002 12:30 AM
> To: 'Jetspeed Users List'
> Subject: RE: jetspeedUser.setPerm() does not work???
>
>
>
>
> > -----Message d'origine-----
> > De : David Sean Taylor [mailto:david@;bluesunrise.com]
> >
> > > From: Gopi Kandaswamy [mailto:gkandasw@;cs.indiana.edu]
> > >
> > > Hi,
> > >
> > > I am using jetspeed-1.4b1 (stable release).
> > >
> > > I do a jetspeedUser.setPerm to store an object and use
> > > jetspeedUser.getPerm to
> > > retrieve it. But I can retrive it only during the current
> > session. If I
> > > logout and then log in, I cannot retrieve it.
> > >
> > > May I know how to retrieve it even after I log out and log in again.
> >
> > try changing the JetspeedResources.properties:
> >
> > automatic.logout.save = true
>
> I'm sorry David, but this is broken, I tried it last week on
> 1.4b1. It uses
> the data.getUser(), and on logout classes, this returns a
> nullpointernullexception...
>
> See this discussion :
>
http://www.mail-archive.com/jetspeed-user%40jakarta.apache.org/msg06400.html
> It should use getUserFromSession() that works, but I don't know why
getUser
> returns null only on logout...
ok, its fixed and in cvs. Thanks.
I was going to follow up on this thread, but I lost sight of it.
Was there a bug logged?
I think its bad that there are two calls in TurbineUser: getUserFromSession
and getUser.
This is the last interface that I left in when converting to 1.4 security.
It just impossible to untangle it from everything.
It appears that Turbine treats login logout action differently. Here are the
comments in Turbine.java
// Special case for login and logout, this must happen before the
// session validator is executed in order either to allow a user
to
// even login, or to ensure that the session validator gets to
// mandate its page selection policy for non-logged in users
// after the logout has taken place.
So if we are executing the action.login or action.logoff, then Turbine
treats these actions special and executes them before the session validator
and access controller. I suspect thats why RunData.getUser has not yet been
populated, but its still in the session.
We could always set action.logoff to something else besides the real logoff
action.
I believe the logic is that after you logoff, you then want the session
validator to kickin and make its appropriate checks against an anonymous
user.
If you didn't do this, the validator would be called upon the session about
to go away
--
To unsubscribe, e-mail: <mailto:jetspeed-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-user-help@;jakarta.apache.org>
