Did you try adding in a SessionBindingListener or a
SessionAttributeListener so that you can see stuff being bound into
the session, too? I'm not sure if they just bind in one big object to
keep track of their state or if they bind each bean as an individual
attribute.
On 8/27/07, Rich Schramm <richard.schramm@xxxxxxxxxxxxxxxxxx> wrote:
> I took James suggestion and added session listeners to the app. It
> appears (see below) that a new session is being created automatically as
> soon as I redirect to the logout or index page. Using redirect, I am
> getting the behavior I expect (the user is prompted to login before
> getting to the home page) but the user is still using the session that
> was created for them after the session was destroyed but before they are
> prompted to authenticate (with the user object accompanying it). After
> authenticating, they have the correct user principle, but the session
> from the last user (with the last user's user object). See below:
>
> 08-27@14:55:35 DEBUG (SessionMgmt:26) - SessionMgmt Class
> instantiated.
> 08-27@14:55:35 DEBUG (SessionMgmt:50) - Logout listener called.
> Destroying Session...
> 08-27@14:55:35 DEBUG (SessionEventListener:25) - Session Destroyed.
> 08-27@14:55:35 DEBUG (SessionMgmt:55) - Session should now be
> destroyed. About to redirect via response.sendRedirect.
> 08-27@14:55:35 DEBUG (SessionMgmt:57) - Redirecting...
> 08-27@14:55:35 DEBUG (SessionMgmt:59) - Redirection sent.
> 08-27@14:55:35 DEBUG (SessionEventListener:20) - Session Created.
> 08-27@14:55:35 DEBUG (User:31) - User Class instantiated.
>
> So - why (and how) would it create a new user session prior to
> authentication, and subsequently why would it create a new managed bean
> user object during that process when it is not called by anything? And
> why would it not instantiate the OTHER 3 managed beans during that
> process?
>
> I am using the 1.2 RI. If you know of a way to hook into the RI to see
> where and why the session and managed beans are instantiated, I would
> appreciate you passing that on.
>
> Thanks,
>
> Rich
>
> -----Original Message-----
> From: gnieman@xxxxxxxx [mailto:gnieman@xxxxxxxx]
> Sent: Monday, August 27, 2007 1:21 PM
> To: users@xxxxxxxxxx
> Subject: Re: [cinjug-users] JSF - managed bean lazy instantiation not so
> lazy - session.invalidate()
>
> Alternatively, depending on which implementation/version you are using,
> there is source that you could step through to see where the user prefs
> object was coming from at the time. If you are on 1.2 of the Sun RI or
> on MyFaces, it should be easy to hook up. That would probably provide
> the definitive answer - it appears as though the session handling is
> correct, but that the JSF context, which I believe is servlet context
> level is using a reference from the previous session.
>
>
> ---- James Carman <james@xxxxxxxxxxxxxxxxxxxx> wrote:
> > Rich,
> >
> > Have you tried setting up an
> > HttpSessionListener/HttpSessionBindingListener so that you can see
> > exactly what's going on and when?
> >
> > James
> >
> > On 8/27/07, Rich Schramm <richard.schramm@xxxxxxxxxxxxxxxxxx> wrote:
> > > Hi,
> > >
> > > I had originally set up the page flow to send them to the index.jsp,
> > > which redirects to the home page. When I discovered the issue I was
> > > having, I put the intermediate logout page in place in an effort to
> > > prevent this (unsuccessfully). Managed beans are loaded into the
> > > session scope by JSF (if so configured in the config file).
> > >
> > > To be more clear, I basically have an action listener in a
> sessionMgmt
> > > object (request scoped). That bean has a logout method which simply
> > > invalidates the session and returns the string that navigation uses
> to
> > > direct the user to the logout or home page. During this
> redirection, it
> > > appears that a new session is created, and JSF is then instantiating
> the
> > > User object with the credentials of the old user. Once the user
> lands
> > > on the logout page, there is a link to the home page. They click
> the
> > > link and are asked to authenticate. Once they authenticate, it does
> NOT
> > > create a new user bean because they are still attached to the
> session
> > > that was created during the logout process and that session already
> > > contains the User bean from the old user.
> > >
> > > The gist of it is, if I am signed in as me, and then logout and sign
> in
> > > as someone else, I have the user principle of the new user, and
> session
> > > (and User bean) of the previous user.
> > >
> > > I would love to have the session only created AFTER authentication,
> but
> > > that is where my problem seems to lie.
> > >
> > > Hopefully that is more clear - any thoughts?
> > >
> > >
> > > Rich
> > >
> > > -----Original Message-----
> > > From: gnieman@xxxxxxxx [mailto:gnieman@xxxxxxxx]
> > > Sent: Monday, August 27, 2007 12:01 PM
> > > To: users@xxxxxxxxxx
> > > Subject: Re: [cinjug-users] JSF - managed bean lazy instantiation
> not so
> > > lazy - session.invalidate()
> > >
> > > I can't see your app, so I'm kind of flying blind here. But I do
> have a
> > > couple of questions. I assume that the logout page is just a
> display
> > > telling them they have logged out? Since you have already logged
> them
> > > out, it seems as though anything else would be kind of futile. Any
> > > reason why you just don't send them back to the login page? Or just
> > > redirect them to the home page and allow the login page to come up
> that
> > > way? It isn't like clicking the home link is ever going to send
> them
> > > anywhere else so it seems like kind of a wasted effort. Same
> overall
> > > result, and there aren't as many pages to manage, flow-wise.
> > >
> > > I got a bit lost on the old user bean/new user bean/user principle
> > > explanation. But it seems like the easiest way to have done this
> would
> > > be to simply invalidate the session and allow the next
> authentication to
> > > create the new user bean the same way as would occur at first login.
> I
> > > assume you are allowing JSF to manage them at session scope. As I
> said,
> > > I'm having kind of a hard time following the exact steps, but the
> thing
> > > to keep in mind here is that when you invalidate the session, you
> don't
> > > necessarily do away with any objects that in in the session. If
> > > anything else has a reference to an object in that session, it is
> still
> > > there in memory. So you may be running afoul of the convention JSF
> is
> > > using the manage the bean instances.
> > >
> > > As for the logout.jsp getting run through the faces servlet, what
> > > servlet path is it configured for? If you are using the default and
> the
> > > url coming in is <some context>/faces/<whatever> it is going through
> the
> > > servlet. Check the path - again, not sure exactly what you are
> > > currently doing so not sure what to tell you in terms of how to fix
> it.
> > > Mileage may vary.
> > >
> > > I'm not a really JSF expert at this stage, but those are the kinds
> of
> > > things I'd look at.
> > >
> > > gn
> > >
> > > ---- Rich Schramm <richard.schramm@xxxxxxxxxxxxxxxxxx> wrote:
> > > > Hello,
> > > >
> > > > I am creating a web app in JSF RI with richfaces and facelets. I
> have
> > > a
> > > > session scoped managed been that stores preferences for the user
> who
> > > is
> > > > signed in.
> > > >
> > > > The problem I am having is that when the user logs out. I
> invalidate
> > > the
> > > > session and send the user to the logout page. On it's way to the
> > > logout
> > > > page, it creates a new session for the user and instantiates the
> user
> > > > managed bean again. The user lands at the logout page, then clicks
> the
> > > > link to the home page. The system (properly) redirects him to the
> > > login
> > > > page where he authenticates and goes to the home page. However, at
> > > that
> > > > point the session is already there, so that he has the user
> principle
> > > of
> > > > the new user with the User bean of the old user.
> > > >
> > > > I have, of course, checked to make sure that the logout page does
> not
> > > > contain any reference to the User bean. In fact, I created a new
> home
> > > > page with no reference to the user bean and the logout page has no
> > > > reference to it, nor do the phase listeners. I actually commented
> the
> > > > bean out of the faces config file and the modified home page /
> logout
> > > > loop work fine without it (since it is not called anywhere). Once
> I
> > > > uncomment it, the bean instantiates itself again. None of the
> other
> > > > managed beans instatiate themselves with a new session, only this
> one
> > > > (there are 2 others).
> > > >
> > > > I am sure I could work around this issue if I needed to, but I am
> > > trying
> > > > to understand what is going on with this?
> > > >
> > > > On a separate but related note, I am having trouble making my
> logout
> > > > page NOT be run through the faces servlet. It is in the same
> directory
> > > > and same extension (.jsp) as my login.jsp page, and that page is
> not
> > > > processed by the servlet, but logout.jsp is.
> > > >
> > > > BTW, we are looking to add another JSF/Portlet developer to our
> team.
> > > > If you are interested let me know. If you are interested and can
> help
> > > > me fix this, you are well on your way to a new job.
> > > >
> > > > Thanks,
> > > >
> > > > Rich
> > > >
> > >
> > >
> > > ---------
> > > You may unsubscribe from this mailing list
> > > by sending a blank email addressed to:
> > > users-unsubscribe@xxxxxxxxxx
> > >
> > > --
> > > Find additional help by sending a blank email
> > > addressed to:
> > > users-help@xxxxxxxxxx
> > >
> > >
> > >
> ________________________________________________________________________
> > > _____
> > > Scanned by IBM Email Security Management Services powered by
> > > MessageLabs. For more information please visit
> http://www.ers.ibm.com
> > >
> ________________________________________________________________________
> > > _____
> > >
> > > ---------
> > > You may unsubscribe from this mailing list
> > > by sending a blank email addressed to:
> > > users-unsubscribe@xxxxxxxxxx
> > >
> > > --
> > > Find additional help by sending a blank email
> > > addressed to:
> > > users-help@xxxxxxxxxx
> > >
> > >
>
>
> ---------
> You may unsubscribe from this mailing list
> by sending a blank email addressed to:
> users-unsubscribe@xxxxxxxxxx
>
> --
> Find additional help by sending a blank email
> addressed to:
> users-help@xxxxxxxxxx
>
>
> ________________________________________________________________________
> _____
> Scanned by IBM Email Security Management Services powered by
> MessageLabs. For more information please visit http://www.ers.ibm.com
> ________________________________________________________________________
> _____
>
> ---------
> You may unsubscribe from this mailing list
> by sending a blank email addressed to:
> users-unsubscribe@xxxxxxxxxx
>
> --
> Find additional help by sending a blank email
> addressed to:
> users-help@xxxxxxxxxx
>
>
|