This really bugged me, so I actually put something like this together
tonight. Stepping through the code, when I invalidate the session, and
come back to the login, there is nothing in my User bean. Using the JSF
1.2 RI, Tomcat 6.0.13, and the 1.6.0,02 JDK.
I just modified one of the example programs from the book I'm working
through: JavaServer Faces: The Complete Reference. It was pretty close
to start off with, I would think. If you go out to the example site
and get chapter 9, you can run it yourself to see what the differences
might be.
http://www.jsfcompref.com/code_download.html
HTH,
gn
Rich Schramm wrote:
Aside from showing me explicitly that the session is destroyed and
recreated, I am not certain what good an attribute or binding listener
will do. I know the user object is being instantiated as I can see it
in my debug code in the constructor and I know it is getting put into
the session. I guess I am not sure what I would be looking for??
Richard Schramm
Supply Dynamics, LLC.
513.965.2000 x14 (office)
513.300.7851 (mobile)
http://www.supplydynamics.com/
-----Original Message-----
From: jcarman@xxxxxxxxxxxxxxxxxxxx [mailto:jcarman@xxxxxxxxxxxxxxxxxxxx]
On Behalf Of James Carman
Sent: Monday, August 27, 2007 3:13 PM
To: Rich Schramm
Cc: gnieman@xxxxxxxx; users@xxxxxxxxxx
Subject: Re: [cinjug-users] JSF - managed bean lazy instantiation not so
lazy - session.invalidate()
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
________________________________________________________________________
_____
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
|